Notes
(0040340) pavel.odintsov (reporter) 2016-01-28 07:46	Actually you could look at awesome implementation of LTO feature from Nils Gladitz https://github.com/ngladitz/cmake/tree/gcc-ipo [^]

(0040344) Brad King (manager) 2016-01-28 08:51	Re 0015939:0040340: Nils is a regular contributor to CMake. I've added him to Cc. Nils, is this work something you intend(ed) to integrate upstream?

(0040345) Nils Gladitz (developer) 2016-01-28 09:11	From what I can tell I had this merged to next but reverted it after you interjected that the extra checking I perform for the LTO wrappers runs irregardless of users opting for IPO or not. You suggested that it might be possible to defer these checks until CMake knows that IPO has been requested using the then still in progress target_compile_features() but I haven't been able to figure out how to do that. (Mail thread was off-list "hythloth.kitware" / "gcc-ipo topic" ~ 2014-02-06)

(0040346) Brad King (manager) 2016-01-28 09:21	Re 0015939:0040345: Yes, I remember now, thanks. Since that conversation was not on-list, here are the relevant messages: On 02/10/2014 11:19 AM, Brad King wrote: > This adds quite a bit of logic that runs on every first config > whether users want IPO or not. I wonder if we can delay the > check until we really need to know the result, perhaps with > changes to the C++ code for the feature. This may tie into > Steve K's target_compiler_feature work. > > It also adds user-visible variables like CMAKE_GCC_AR and > CMAKE_GCC_RANLIB that may be confusing versus CMAKE_AR and > CMAKE_RANLIB. What is the difference and the justification? > > Also, any tests in the language init modules that need to be > saved persistently, like CMAKE_${lang}_PASSED_LTO_TEST, need > to be configured into CMake<lang>Compiler.cmake instead of > put in the cache. This file is specific to the version of > CMake that ran the test but the cache is not. ------------------------------------------------------------------------ On 02/10/2014 12:04 PM, Nils Gladitz wrote: >> It also adds user-visible variables like CMAKE_GCC_AR and >> CMAKE_GCC_RANLIB that may be confusing versus CMAKE_AR and >> CMAKE_RANLIB. What is the difference and the justification? > > I'll add documentation strings for them and mark them advanced. > CMAKE_AR and CMAKE_RANLIB are set to ar and ranlib which are part of > binutils. > CMAKE_GCC_AR and CMAKE_GCC_RANLIB are set to gcc-ar and gcc-ranlib which > are wrappers provided by gcc. > The wrappers take a similar role to XIAR which is used in the Intel IPO > setup. ------------------------------------------------------------------------ On 02/14/2014 05:33 AM, Nils Gladitz wrote: > On 02/10/2014 05:19 PM, Brad King wrote: > >> This adds quite a bit of logic that runs on every first config >> whether users want IPO or not. I wonder if we can delay the >> check until we really need to know the result, perhaps with >> changes to the C++ code for the feature. This may tie into >> Steve K's target_compiler_feature work. > > I had a chance to ask Steve about target_compile_features() and it does > sound like it might be a good place for IPO. > > If I understand your implied intend a target feature would be able to > substitute the INTERPROCEDURAL_OPTIMIZATION property for both detection > and flag setup. > > Currently target_compile_features() does not delay checks either but > Steve is taking it under consideration now. > >> Also, any tests in the language init modules that need to be >> saved persistently, like CMAKE_${lang}_PASSED_LTO_TEST, need >> to be configured into CMake<lang>Compiler.cmake instead of >> put in the cache. This file is specific to the version of >> CMake that ran the test but the cache is not. > > According to the documentation I found in the sources (and manual > tracing) the CMake<lang>Compiler.cmake files are already written when > Modules/Compiler/GNU-${lang}.cmake is processed. > > As far as I understand target_compile_features() checks currently run > earlier and would still be eligible for CMake<lang>Compiler.cmake. > > Though I assume this might be a problem again if the checks are delayed > until they are needed (I proposed during evaluation of the > target_compile_features() commands themselves). > > Since it sounds like the topic might take a while before it will get > into master I reverted my commits from "next" for now.

(0040347) Brad King (manager) 2016-01-28 09:27	With target_compile_features mature and integrated we can now rebase and re-evaluate how to add IPO support.

(0040348) pavel.odintsov (reporter) 2016-01-28 09:42	I could participate in testing. I interested in this code :)

(0040349) Nils Gladitz (developer) 2016-01-28 09:58	Steve did not seem to go with deferred testing in his target_compile_features() implementation but the existing feature tests are probably more lightweight than what I did for lto so this is understandable. Which I think leaves either of: - testing for all users even if they don't use the feature - use lto wrappers when INTERPROCEDURAL_OPTIMIZATION is set without testing them

(0040358) Brad King (manager) 2016-01-29 09:34	Re 0015939:0040349: The tests look pretty light-weight and should not have a noticeable impact on the time it takes to enable a language. Might we be able to use the detected compiler version number to avoid full tests in certain cases? > According to the documentation I found in the sources (and manual > tracing) the CMake<lang>Compiler.cmake files are already written when > Modules/Compiler/GNU-${lang}.cmake is processed. IIRC those files are actually configured twice. The first time gets the bare minimum information to use them for a try_compile, which is then used for the ABI check and test for a working compiler. The second time adds the rest of the information. Anyway, we should find the right place to add these checks so that the results can be stored properly and used in try_compile calls.

(0040362) Nils Gladitz (developer) 2016-01-29 10:02	Looking at the "hythloth.kitware" thread I added testing involving both the linker and ar since binutils also requires lto support and dashboards failed at either of those stages (even though the gcc version itself was current enough).

(0040559) pavel.odintsov (reporter) 2016-02-26 11:42	Hi, folks! How I can test this feature?

(0040566) Nils Gladitz (developer) 2016-02-27 19:12	To start with I rebased the topic: https://github.com/ngladitz/cmake/tree/gcc-ipo2 [^]

(0042924) Kitware Robot (administrator) 2016-06-10 14:29	Resolving issue as `moved`. This issue tracker is no longer used. Further discussion of this issue may take place in the current CMake Issues page linked in the banner at the top of this page.

Issue History
Date Modified	Username	Field	Change
2016-01-28 07:40	pavel.odintsov	New Issue
2016-01-28 07:46	pavel.odintsov	Note Added: 0040340
2016-01-28 08:51	Brad King	Note Added: 0040344
2016-01-28 09:11	Nils Gladitz	Note Added: 0040345
2016-01-28 09:21	Brad King	Note Added: 0040346
2016-01-28 09:27	Brad King	Note Added: 0040347
2016-01-28 09:42	pavel.odintsov	Note Added: 0040348
2016-01-28 09:58	Nils Gladitz	Note Added: 0040349
2016-01-29 09:34	Brad King	Note Added: 0040358
2016-01-29 10:02	Nils Gladitz	Note Added: 0040362
2016-02-26 11:42	pavel.odintsov	Note Added: 0040559
2016-02-27 19:12	Nils Gladitz	Note Added: 0040566
2016-06-10 14:29	Kitware Robot	Note Added: 0042924
2016-06-10 14:29	Kitware Robot	Status	new => resolved
2016-06-10 14:29	Kitware Robot	Resolution	open => moved
2016-06-10 14:29	Kitware Robot	Assigned To	=> Kitware Robot
2016-06-10 14:31	Kitware Robot	Status	resolved => closed

Relationships