http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45810
--- Comment #6 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-09-28 14:07:54 UTC --- (In reply to comment #5) > (In reply to comment #4) > > Sure. As with all performance related bugs this needs analysis and is > > unlikely an "LTO" problem - LTO does not (not-)optimize, optimization > > passes do. > > I'm wondering if there is any description on how to do this. For example, how > do I get the assembly of a function and the -fdump-tree-all files from a gold > based linking that goes as: > > rm -f test.s test2.s test.o test2.o ; > gfortran -c -flto test.f90 ; > gfortran -c -flto test2.f90 ; > gfortran -O3 -march=native -fuse-linker-plugin -fwhopr=2 test.o test2.o > > just using -S or -fdump-tree-all doesn't work. > > Is 'objdump -d' the only tool ? No, -fdump-tree-all works, it just uses maybe un-intuitive base-names. Append -v to see them, for -fwhopr it should be the output file specified with -o (which you leave out which causes us to use not a.out but some temporary file in /tmp), with -o t I get t.ltrans[01].147t.optimized, etc. With -flto it's just t.147t.optimized. To retain assembler you have to use -save-temps which retains t.ltrans[01].s, with -flto it retains t1.s (using the base of the first object file).
