|
From: Robert W. <rjw...@ic...> - 2017-11-14 00:07:49
|
What kind of speed up do you see for non-LTO test cases run against LTO tool? Interested in how much of the speed up is attributable to the tool. Sent from my iPhone > On Nov 13, 2017, at 2:15 PM, Philippe Waroquiers <phi...@sk...> wrote: > >> On Mon, 2017-11-13 at 11:43 +0100, Ivo Raisr wrote: >> 2017-11-11 23:27 GMT+01:00 Philippe Waroquiers <phi...@sk...>: >>> This mail gives some measurements of the perf impact of using link time >>> optimisations when building valgrind with lto (NB: some hacks >>> documented below were used to build with -flto). >>> >>> A summary of the perf impact is: >>> * callgrind : all perf tests are faster (between 5 to 10%). >>> * memcheck : many tests are faster, some are equal, one degraded >>> (I retried this one later, there was then no degradation). >>> * helgrind : many tests are faster, a few are slower. >>> >>> The regression tests seem basically ok (some 30 failures mostly >>> due to some stacktraces differences, as the tests were also >>> compiled with -flto). >> >> Splendid job, Philippe! >> >> Some of the problems could go away if "fat" object files were used >> (-ffat-lto-objects). > Yes, providing fat objects will allow to produce only one library > version, usable to link with or without lto. > >> >> What I am worrying now is about observability of LTO-built valgrind binaries. >> Every section of gcc manual says that support for debugging information with LTO >> is experimental and that it can produce unexpected results. >> What are your findings here? Were you able to get some useful information >> for example from Valgrind C source code, and from VEX helper functions >> called by generated code? > I did not had to debug anything, so I cannot really judge but > I just tried now some debugging by doing --wait-for-gdb=yes, then put > a few breakpoints, look at so,e variables and args, next and step. > In this small experiment, I had no particular problem to debug. > So, the debugging experience seems not particularly worse than the > current -O2 setup. > But in any case, I think we should probably support both lto and non > lot versions, just in case ... > > Philippe > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |