> > This is why we currently have way to order function when outputting them > > and use that with FDO (using Martin's first execution logic). This has > > drwarback of making the functions to flow in that order through late > > optimizations and RTL backend and thus we lose IPA-RA and some > > IP propagation (late pure/const/nothrow discovery). > > But you can also fix that by the parallelization GSoC project approach, > decoupling things at RTL expansion IPA-wise and using output order > for the latter (or even do the fragments in GCC itself by refactoring the > output machinery to use function-local "strings", assembling the final > file later). Refactoring output to handle multiple output "files" at the > same time might also help getting rid of that early-LTO-debug copying > stuff (now that it seems that linker-plugin extensions for partially claiming > files will never happen...)
Multiple output files won't solve my concern about padding and relaxation, but yep, parallelizing RTL will definitly need to introduce way to hold final assembly and glue it together, so this problem may get solved independently which would be nice. Honza
