|
From: Philippe W. <phi...@sk...> - 2017-11-13 22:15:10
|
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 |