I had the same problem, so I did some research. According to: If you compile your program with /GL and /c, you should use the /LTCG linker option to create the output file. So the message can be a bit misleading - the problem is not the MSIL.netmodule, but modules compiled with /GL When using /GL, you tell the compiler to delay the generation of some code namely around function bounderies, in order to optimise them. LTCG instruct the linker to generate (and optimise) the missing code. Otherwise, the program will not run as expected. Basically, the two switches should be used together (when used).
They apply to different parts of the build: one for compilation and the other one for link. For completeness:. /GLis controlled from Configuration Properties C/C Optimization Whole Program Optimization.
/LTCG is controlled from Configuration Properties Linker Optimization Whole Program Optimization On later versions,. /LTCG is controlled from Configuration Properties Linker Optimization Link Time Code Generation / Use Link Time Code Generation (/LTCG). I have encountered the same error and spent quite a lot of time trying to fix it. Finally, I figured out that it appeared due to the use of 'Whole Program Optimization' option in one of my dependency libraries.
By default, this option is set to 'Yes' in newly created projects. When I changed it to 'No' and recompiled all dependencies, the warning disappeared. I have purely native C solution without any managed code. To fix, open project settings of all dependency projects and check setting: Configuration Properties C/C Optimization Whole Program Optimization Make sure it is set to 'No' everywhere. 'Link Time Code Generation' setting is a better alternative. However, it is not always convenient because it is not a default setting. Imagine that you supply a library for a wide audience.
You must write then an instruction on adjusting settings in every end project consuming the library. Potential users of the library might grow suspicious and simply select not using it in their projects. Changing setting in C options harms the efficiency but allows to reach compatibility to defaults. Which scenario to choose everybody should decide individually depending on concrete circumstances.
– May 26 '15 at 8:53.
I am trying to test the new /LTCG:incremental option (VS2015 only) to reduce the pain of our incremental builds. I believe I should be seeing some.iobj and.ipdb files that hold the incremental link info. I do not see these.
I suspect that my projects, having been migrated from VS2012, do not have all the correct settings. Can someone please list which options I should be setting for:. 3 static libraries. 2 DLLs. 1 EXE file The place where options must be set includes General/ Compiler/ Linker/ Librarian. Background on incremental build improvements can be found on the VC Team BLog from Nov 2014, but the VS2015 documents are not exactly crystal clear on how to turn this on. Hi Steve, Currently, it seems that the issue you met is located on the legacy project, however because I can not reproduce the issue, so I am not sure if the issue is definitely due to migration.
Maybe some other options impact. Due to the new function 'Fast Link Time Code Generation' has not detailed introduction in MSDN document, I would suggest you see the blog in link below and write your issue in the blog comment, there should be MSFT from the product team to help you.
And the fast tips for faster builds in link below for your reference. May We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place. Click to participate the survey. Hi, Thanks for posting here.
What kind of build did you do? There is no Link Time Code Generation setting for debug build by default. The release build is set 'Use Fast Link Time Code Generation (/LTCG:incremental)'. When I build with release, I can see.iobj and.ipdb files in my release folder.
Samsung gravity smart. More about /LTCG (Link-time Code Generation) in VS2015, you may refer to MSDN document in link below. May We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time.
Thanks for helping make community forums a great place. Click to participate the survey. Hi - thanks for the reply. Yes, I had that setting as you suggested, and also the one on the General page, and any others I could find that are supposed to trigger LTCG:incremental. My build does not produce the files you noticed, and the link time still appears to involve full code generation on even the most trivial code change.
The documentation link you posted (which is the one I mentioned in my post) does not mention LTCG:incremental anywhere as far as I can tell. Is this an unsupported option, or is the documentation deficient?
Your screenshot seems to be from a toy app created to demonstrate the correct settings. I wonder if my use case, which is migration of a large 6 project solution from an earlier version (VS2012), is causing some type of hidden failure to trigger LTCG:incremental even though I ostensibly have all the compiler and linker flags set correctly? At this point, the interaction of all these General/Compiler/Librarian/Linker options is really hard to fathom, and revised documentation might go a ways towards helping with that.
I am building Release. We also have the standard Debug (which we rarely use because its execution speed is so slow) and Release-NoOpt which is our own variation, using Release code with compiler optimization and LTCG turned off, to speed up the desktop incremental build. I made my own toy app and I do see that the LTCG:incremental setting is the default.
So I think it's likely that this is an issue specific to my migration of existing projects. All 1 functions were compiled because no usable IPDB/IOBJ from previous compilation was found. I noticed in the toy project that the Release x86 and Release x64 has an extra property sheet for 'Whole Program Optimization'. This is (obviously I guess) not present in my migrated projects, since it was not present in the original versions. Maybe if I can track down how to add this sheet to my migrated projects, the new LTCG:incremental support will work?
I did manage to track this property sheet down, it's being include by default but does not result in expected behaviour. Hi, Yes, I had that setting as you suggested, and also the one on the General page, and any others I could find that are supposed to trigger LTCG:incremental. My build does not produce the files you noticed, and the link time still appears to involve full code generation on even the most trivial code change. I made my own toy app and I do see that the LTCG:incremental setting is the default. So I think it's likely that this is an issue specific to my migration of existing projects.
Thanks for your feedback. Based on your testing, it seems that the issue is mainly located on the migration projects. So double check if the projects are enabled with incremental link. It seems that the projects are performing full link. Modify the Enable Incremental Linking property with /INCREMENTAL When this option is selected, the linker issues a warning if it cannot link incrementally, and then links the program nonincrementally. Most programs can be linked incrementally. However, some changes are too great, and some options are incompatible with incremental linking.
![]() David R Cok
LINK performs a full link when some special scenarios. The detailed scenarios please goto check. May We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place. Click to participate the survey. That's not really practical, it's many 1000s of lines of code and depends on several other libraries, one of which is a third-party licensed package.
I don't have time to try to reproduce in a smaller version, particularly since my guess is that this involves the project migration process from VS2012. Can you suggest some MSBuild or other diagnostics that would help the dev team understand why LTCG:/incremental is not being triggered? Does the dev team think that migrating via VS2013 rather than direct from VS2012 to VS2015 would be more likely to succeed? Hi Steve, Currently, it seems that the issue you met is located on the legacy project, however because I can not reproduce the issue, so I am not sure if the issue is definitely due to migration. Maybe some other options impact.
Due to the new function 'Fast Link Time Code Generation' has not detailed introduction in MSDN document, I would suggest you see the blog in link below and write your issue in the blog comment, there should be MSFT from the product team to help you. And the fast tips for faster builds in link below for your reference. May We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place. Click to participate the survey.
I am trying to test the new /LTCG:incremental option (VS2015 only) to reduce the pain of our incremental builds. I believe I should be seeing some.iobj and.ipdb files that hold the incremental link info. I do not see these. I suspect that my projects, having been migrated from VS2012, do not have all the correct settings. Can someone please list which options I should be setting for:. 3 static libraries. 2 DLLs.
1 EXE file The place where options must be set includes General/ Compiler/ Linker/ Librarian. Background on incremental build improvements can be found on the VC Team BLog from Nov 2014, but the VS2015 documents are not exactly crystal clear on how to turn this on.
Tom Johnson
Hi Steve, Currently, it seems that the issue you met is located on the legacy project, however because I can not reproduce the issue, so I am not sure if the issue is definitely due to migration. Maybe some other options impact. Due to the new function 'Fast Link Time Code Generation' has not detailed introduction in MSDN document, I would suggest you see the blog in link below and write your issue in the blog comment, there should be MSFT from the product team to help you.
And the fast tips for faster builds in link below for your reference. May We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place. Click to participate the survey.
Hi, Thanks for posting here. What kind of build did you do? There is no Link Time Code Generation setting for debug build by default. The release build is set 'Use Fast Link Time Code Generation (/LTCG:incremental)'.
When I build with release, I can see.iobj and.ipdb files in my release folder. More about /LTCG (Link-time Code Generation) in VS2015, you may refer to MSDN document in link below. May We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time.
Thanks for helping make community forums a great place. Click to participate the survey. Hi - thanks for the reply. Yes, I had that setting as you suggested, and also the one on the General page, and any others I could find that are supposed to trigger LTCG:incremental. My build does not produce the files you noticed, and the link time still appears to involve full code generation on even the most trivial code change. The documentation link you posted (which is the one I mentioned in my post) does not mention LTCG:incremental anywhere as far as I can tell.
Is this an unsupported option, or is the documentation deficient? Your screenshot seems to be from a toy app created to demonstrate the correct settings. I wonder if my use case, which is migration of a large 6 project solution from an earlier version (VS2012), is causing some type of hidden failure to trigger LTCG:incremental even though I ostensibly have all the compiler and linker flags set correctly? At this point, the interaction of all these General/Compiler/Librarian/Linker options is really hard to fathom, and revised documentation might go a ways towards helping with that. I am building Release.
We also have the standard Debug (which we rarely use because its execution speed is so slow) and Release-NoOpt which is our own variation, using Release code with compiler optimization and LTCG turned off, to speed up the desktop incremental build. I made my own toy app and I do see that the LTCG:incremental setting is the default. So I think it's likely that this is an issue specific to my migration of existing projects.
All 1 functions were compiled because no usable IPDB/IOBJ from previous compilation was found. I noticed in the toy project that the Release x86 and Release x64 has an extra property sheet for 'Whole Program Optimization'. This is (obviously I guess) not present in my migrated projects, since it was not present in the original versions. Maybe if I can track down how to add this sheet to my migrated projects, the new LTCG:incremental support will work? I did manage to track this property sheet down, it's being include by default but does not result in expected behaviour. Hi, Yes, I had that setting as you suggested, and also the one on the General page, and any others I could find that are supposed to trigger LTCG:incremental.
My build does not produce the files you noticed, and the link time still appears to involve full code generation on even the most trivial code change. I made my own toy app and I do see that the LTCG:incremental setting is the default. So I think it's likely that this is an issue specific to my migration of existing projects. Thanks for your feedback.
Based on your testing, it seems that the issue is mainly located on the migration projects. So double check if the projects are enabled with incremental link. It seems that the projects are performing full link. Modify the Enable Incremental Linking property with /INCREMENTAL When this option is selected, the linker issues a warning if it cannot link incrementally, and then links the program nonincrementally. Most programs can be linked incrementally. However, some changes are too great, and some options are incompatible with incremental linking.
LINK performs a full link when some special scenarios. The detailed scenarios please goto check. May We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place. Click to participate the survey. That's not really practical, it's many 1000s of lines of code and depends on several other libraries, one of which is a third-party licensed package.
I don't have time to try to reproduce in a smaller version, particularly since my guess is that this involves the project migration process from VS2012. Can you suggest some MSBuild or other diagnostics that would help the dev team understand why LTCG:/incremental is not being triggered? Does the dev team think that migrating via VS2013 rather than direct from VS2012 to VS2015 would be more likely to succeed? Hi Steve, Currently, it seems that the issue you met is located on the legacy project, however because I can not reproduce the issue, so I am not sure if the issue is definitely due to migration.
Mathemati…
Maybe some other options impact. Due to the new function 'Fast Link Time Code Generation' has not detailed introduction in MSDN document, I would suggest you see the blog in link below and write your issue in the blog comment, there should be MSFT from the product team to help you. And the fast tips for faster builds in link below for your reference. May We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place. Click to participate the survey.
Hi, I’m Jerry Goodwin from the Visual C code generation and optimization team, with a couple quick tips on using Whole Program Optimization, also referred to as Link Time Code Generation (LTCG). If you’re writing native C code, you can typically speed up your optimized code by about another 3-4% by adding the /GL flag to your compiles. This flag tells the compiler to defer code generation until you link your program. Then at link time the linker calls back to the compiler to finish compilation. If you compile all your sources this way, the compiler optimizes your program as a whole rather than one source file at a time. For users building with the IDE, this option is found under the C/C optimization settings, and is already on by default for retail builds in new projects.
Using Whole Program Optimization provides the optimizer with a number of extra optimization opportunities, but I’ll give just one example. Many people are already familiar with the benefits of inlining a called function into the caller. We can only do inlining when we are generating code for both the calling function and the called function at the same time. With Link Time Code Gen we can inline functions from one source file into callers defined in another source file, as long as both source files were compiled with /GL.
If you do use /GL, here are four caveats to keep in mind: 1. When building from the command line or via makefiles, you need to add the /LTCG switch to the link command line to tell the linker to expect to see one or more object files that were compiled with /GL.
If you don’t, some build time will be wasted because the linker will have to start over when it gets to the module compiled with /GL. If you build through the IDE this is in your project configuration settings on the Linker optimization page. Using /GL reduces your compile times, but your link time will increase, because work is being moved to during the link. Overall build time might increase a little, but shouldn’t increase a lot. Don’t compile managed code with /GL. Link time code gen provides little or no benefit to managed code, and this option combination (/GL /clr) is being removed in the next compiler release, so you can future-proof your build by using link time code generation only for native code. If you’re building managed code using the IDE, the default setting is to use /GL in release builds, and I recommend you disable it for managed code.
For mixed managed and native code, compiling only the native code with /GL and linking with /LTCG gives best results. Never use /GL for code you intend to put in a library and ship to your customers. Doing so means that your customers will be doing the code gen for your library when they link their application. Since some of your customers could have different versions of the compiler, shipping a lib built this way could cause various maintenance problems for you. If your customer’s compiler is from a prior release, their link may fail. If their version is newer than yours, the code they generate won’t be exactly equal to what you’ve tested, and could behave differently for them than when you tested it. In VS 2008, the IDE default for the class library template release configuration is to build using /GL, and I strongly encourage everyone to reset that.
Here are links for more information on this topic: ( ) ( ) ( ). In a non-LTCG compile, we already have W4-level warnings that indicate when a function you didn’t ask to be inlined was inlined (C4711) and for the case where you did ask for something to be inlined but it wasn’t (C4710).
There’s also the C4714 case where a function you marked forceinline can’t be inlined for some reason. These messages are emitted during code generation, so in the LTCG case you’d see the same messages emitted during the link step. But to enable them you have to turn them on when compiling, because they’re compiler command line options, not linker command line options.
All the options the compiler would normally pass to the code generator in a regular compile are saved in the /GL-format.obj file and then the code generator honors them when the linker calls the code generator at link time. Another option like this is /wdNNNN (which you might want to use along with /W4 to filter warnings you aren’t interested in). I have just installed VS 2008 alongside my old VS 2005, all of them fully updated (service packs) and it seems the VS 2008 cl.exe (Compiler Version 9.01) is slower than the VS 2005 one (Compiler Version 7.762). Is it correct? I have tested it with a lot of projects and it seems the 2008 one is about 30% slower than the old compiler. I am really disappointed:( Example of cmd line (have tested tons of options but the new compiler is always slow): cl /O2 /I 'G:Boost-1.38.0include' /I 'G:zlib-1.2.3include' /I './Include' /D 'WIN32' /D 'NDEBUG' /D 'LIB' /D 'UNICODE' /D 'UNICODE' /FD /EHsc /MD /Fo'Release ' /Fd'.Releasevc90.pdb' /W3 /c /Zi /TP /MP 'file1.cpp' 'file2.cpp' 'file3.cpp' 'file4.cpp' 'file5.cpp' 'file6.cpp' 'file7.cpp' 'file8.cpp'. @Dollyan, it’s not clear whether you’re talking about compiler throughput (compile time) or compiler code quality (run time of the compiled code).
We continuously benchmark our compiler against a range of performance suites and I’m sure we didn’t see any 30% drops. If you’re talking about code quality I suspect you may be comparing an optimized build from VS 2005 to a non-optimized build from VS 2008. The issue linked above has something to do with losing an optimization setting in the project during conversion from VS 2005 to VS 2008, but I’m not up on the details of that issue.
That problem was fixed in the VS 2008 SP1 update, though you may need to reset some of your project settings for the projects you have already converted. If you suspect that is the problem, you can eliminate the IDE and its build system from the variables by building from the VS Command Prompt. If you can reproduce this performance drop with sources you are willing to share with us we’d request that you open an MSConnect issue, because we’d be happy to be able to look at the issue more closely than we can via vcblog. By the way, in reference to the above link.
I reported a bug last year which turned out to be the same thing. That this issue was closed with 'by design' is EXACTLY what pisses me off about the Visual Studio team. This is a bug–anyone who designed such a thing would be a complete moron. I can’t count the number of such bug submissions I’ve made where the VS team has just dismissed them out-of-hand.
A perfect example is my posting above about release performance and size. Executables are measurably more bloated with 2005/2008/2010 than with VC6.
The CRT startup code has always been horrible, but I’ve yet to figure out the rest. VC 6 apps are also faster. If you really want to make VS2010 the next 6, fix these two problems. (If I want bloat, I’ll use.NET; I use C precisely because I want lean and mean; give that back, please. Better yet, make it so the executable code is leaner and meaner.).
@Jerry Goodwin I am talking about compile time, not generated code quality. As I posted before, using the following cmd line (from the VS 2005 and 2008 cmd prompts) shows a compile time for VS 2008 about 30% bigger than with VS 2005’s compiler. I have tested it with a lot of compiler options and diferent projects, and the VS 2008 C compiler is always a lot slower.
Madan no Ou to Vanadis – Berlatar di sebuah dunia fantasy, dimana terjadi sebuah perang besar, antara kerajaan Zheted dan Brune. Madan no ou to vanadis pdf. Madan no Ou to Vanadis 720p BD Eng Sub In a fantasy version of Europe, a war between enemy countries is brewing. One of these countries, Zhcted, has its seven regions ruled by War Maidens, known as Vanadis.
Cl /O2 /I 'G:Boost-1.38.0include' /I 'G:zlib-1.2.3include' /I './Include' /D 'WIN32' /D 'NDEBUG' /D 'LIB' /D 'UNICODE' /D 'UNICODE' /FD /EHsc /MD /Fo'Release ' /Fd'.Releasevc90.pdb' /W3 /c /Zi /TP /MP 'file1.cpp' 'file2.cpp' 'file3.cpp' 'file4.cpp' 'file5.cpp' 'file6.cpp' 'file7.cpp' 'file8.cpp' I have a core2duo and tested both compilers with and without /mp. Compile time (compiler throughput) has to be traded off against code quality (better, tighter, faster generated code). Some customers are going to be more concerned about one, some about the other, depending on what they’re doing. We have to try to find a good balance. Obviously for /Od (non-optimized) compiles we strongly favor throughput over code quality. For optimized compiles it’s a much more difficult balance. I wasn’t here during the VC6 to VC7 development cycle, but in general we’re constantly trying to improve the compiler by adding new optimizations.
Before any new optimization goes in the programmer has to measure and report the impact on code quality and runtime performance. If the change isn’t a win, it doesn’t go in.
We also do continuous measurement of the compiler to detect any performance regressions. Occasionally we discover a bug in the compiler that has to be fixed in a way that impacts performance. Correctness trumps performance. There’s also tuning that goes on, each release of the compiler is targeted at the versions of the processors that are in production at the time we release the compiler. The processor manufacturers are constantly tweaking their designs so that’s something of a moving target. With all these 'moving parts', it’s very easy to pick a single measurement (e.g.
Throughput) and show a single non-representative case where the new compiler is worse than the previous one. And for a given customer, that one case may be the only case that’s important to them, which is unfortunate. The message I’m trying to give is that we pay close attention to all these issues, work hard to constantly improve, continuously measure and report internally, and only accept performance hits for correctness or security issues. I’m not well positioned to respond to the whole issue related to the MSConnect bug linked above, because it’s about the IDE not the code generator, but I’ve been talking to the folks that are. Gujarati books in usa. They’ve been doing some re-investigation, and I’m hoping you’ll see something here on that topic soon.
The bottom line as I see it is that some users were accidentally changed from an optimized compile using VC 8 to a non-optimized compile using VC 9. That’s the only way anyone is going to see a 30% runtime performance degradation between the two releases, and it’s due to a change in the command line parameters passed to the compiler, not the compiler itself. If you are seeing a significant performance reduction between any two releases, I would encourage you to first validate that you’re comparing apples to apples by building the same code from the command line with the same command line flags. If that shows a performance regression, then please open an issue with MSConnect if you can provide us with something we can reproduce here. Jerry Goodwin. @Jerry Goodwin Dude, didnt you read what i wrote? ITS NOT ABOUT RUNTIME PERFORMANCE, ITS ABOUT COMPILE TIME.
And I have used CMD PROMPTS AS I SAID ABOVE, with the same parameters, with only simple parameters, and with a lot of different parameter configurations. Compiler Version 9.01 is always about 30% slower than 7.762). Repeating: I MEAN COMPILE TIME, NOT RUNTIME PERFORMANCE.
I have more than 10 projects, all of them compile 30% slower with the new vs 2008 c compiler. And yes, I have checked all the parameters, they are all correct, all valid, i have tested with tons of parameter cfgs and its always the same. As Gerry mentioned, we make tradeoffs between compile time and the quality of the code we generate. /Od is about keeping build time quick at the expense of code quality, while /O2 builds generate better code at the cost of long builds. As we strive to improve our code quality for /O2 builds, you should see build times increase with newer compilers. I noticed /O2 was one of the parameters you specified on your command line, so it would be interesting to know if you get the same performance changes with /Od instead. The compiler team does spend a good amount of time investigating compiler throughput.
We understand it’s critical to many customers, not only in /Od builds, but also /O2 builds. We have been focusing our performance analysis on comparing VS2010 to VS 2008. Given your feedback, we’ll need to broaden our comparisons to include older versions of the compiler as well. For anyone posting about problems with the compiler, or any tool for that matter, sharing detailed information is critical. Dollyan, the compiler flags were quite useful, but having some idea as to the size of the projects and how many libraries it pulls in would helpful in understanding the cause of the regression. In the coming months we plan on sharing more information about the enhancements we’ve made to the compiler – especially in the area of code generation.
We’ll be sure to also share information about throughput. @Dollyann, if you can’t submit a sample, here’s a couple of things you can do. Add -P to the command line arguments for both VS2005 and VS2008. How much bigger is the resulting.i file for VS2008 vs. This would help us determine if the compiler is slower, or is just compiling more source code. That will help us know what we’re dealing with.
I didn’t see any precompiled header flags in your sample command line. Use of precompiled headers could slash your compile times by 2x (or 10x, depending on the size of your headers). Using precompiled headers will usually offset (or at least amortize) any losses from release to release in compile time due to larger header files. You are right, allowing LTCG for #pragma unmanaged code even when building with /clr could be beneficial. However, we evaluated how many customers were using this feature (using SQM data) and found it to be a very marginal scenario.
We also discussed this change with some major customers and none reported it as an important feature for them. We came to the conclusion that the cost of maintaining and moving forward a very complex implementation outweighed the benefit of this feature, so it has been removed. We instead want to focus on improving LTCG codegen for the 99.99% case where the binary is completely native.
Comments are closed.
|
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |