I've not been following this thread at all. However, skimming the original post, I fail to find a nice summary of what problem is trying to be solved. By reading the rest of the thread I divine that the goal is faster links and better dead code stripping? Making that clearer would help. Naming your sections something other than "safe" (which has *very* different connotations) would help more. However, I question several fundamental assumptions: 1) We should be very certain that -ffunction-sections is not a viable solution as it exists and is well supported in other toolchains and environments. 2) We should talk to other ELF producers and coordinate to make sure we don't end up creating a twisty maze of extensions here. 3) We should step back and consider leapfrogging to a fully specialized format to reap even more performance benefits rather than messily patching ELF. #3 may prove irrelevant if this is the only major hurdle for speeding up ELF links. My impression was otherwise. #2 hasn't been done by the other ELF producers, but we should strive to do better. #1 can be solved via science. On Tue, Jul 30, 2013 at 5:33 PM, Shankar Easwaran <shankare at codeaurora.org>wrote:> On 7/30/2013 5:43 PM, Nick Kledzik wrote: > >> On Jul 29, 2013, at 10:09 AM, Shankar Easwaran wrote: >> >> On 7/29/2013 11:24 AM, Nick Kledzik wrote: >>> >>>> On Jul 25, 2013, at 2:10 PM, Rui Ueyama wrote: >>>> >>>>> Is there any reason -ffunction-sections and -fdata-sections wouldn't >>>>> work? If it'll work, it may be be better to say "if you want to get a >>>>> better linker output use these options", rather than defining new ELF >>>>> section. >>>>> >>>> >From my understanding, -ffunction-sections is a good semantic match. >>>> But it introduces a lot of bloat in the .o file which the linker must >>>> process. >>>> >>>> For reference, with mach-o we just added a flag to the overall .o file >>>> that says all sections are "safe". The compiler always generates safe >>>> object files (unless there is inline code with non-local labels) and always >>>> sets the flag. Hand written assembly files did not have the flag by >>>> default, but savvy assembly programmers can set it. >>>> >>> We could set this flag for ELF too in the ELF header, but it wouldnot >>> not confirm to the ELF ABI. >>> >>> To account safe sections, we should just create an additional section in >>> the ELF (gcc creates a lot many sections to handle executable stack and for >>> LTO). This would just be another section to dictate what sections are safe. >>> >> Or just create a new empty section with a magic name whose existence >> tells the linker that all sections are safe. >> >> Isnt it better to have this flag set for every section in Darwin too, >>> makes it flexible. I am not sure about the ABI concerns on Darwin though. >>> >> I don't see the benefit of that level of detail. Either the compiler >> produced the object file, so all sections are safe. Or it was hand written. >> If hand written, it is much easier to either say all sections are safe or >> none are. Listing which are safe and which are not would be a pain. >> > I can think of two usecases when the compiler needs to emit safe sections > on a section by section basis. > > * code having inline assembly (it only affects the text section) > * the compiler trying to do some optimizations that deals with data placed > outside function boundaries. > > Does this make sense ? > > > Thanks > > Shankar Easwaran > > -- > Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted > by the Linux Foundation > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130730/f665eec1/attachment.html>
On 7/30/2013 7:41 PM, Chandler Carruth wrote:> I've not been following this thread at all. However, skimming the original > post, I fail to find a nice summary of what problem is trying to be solved.The proposal is trying to garbage collect symbols that are not referenced during the link step. In addition this proposal can be extended to keep frequently called functions/data closer to increase cache coherency. 'lld' tries to atomize all the symbols in a section, but the problem it faces on ELF is that, lld needs to tie all the atoms in a section together to respect the ELF section property. This may be relaxed if lld knows at the time of parsing the section contents, that, if you really need to tie all the atoms together in the final ELF image. This proposal is just a way to convey information from the object file to the linker that sections in the object file can be safely converted to atoms, and they need not be tied together in whichever section they reside.> > By reading the rest of the thread I divine that the goal is faster links > and better dead code stripping? > > Making that clearer would help. Naming your sections something other than > "safe" (which has *very* different connotations) would help more."safe" is a property of a section, by which a section can be atomized and the atoms can appear anywhere in the final output file.> > However, I question several fundamental assumptions: > 1) We should be very certain that -ffunction-sections is not a viable > solution as it exists and is well supported in other toolchains and > environments.-ffunction-sections and -fdata-sections would work, but that would require all third party libraries etc to make sure that they are all compiled with -ffunction-sections.> 2) We should talk to other ELF producers and coordinate to make sure we > don't end up creating a twisty maze of extensions here.This is not a problem with the general ELF community since the binutils ld/gold would not atomize sections.> 3) We should step back and consider leapfrogging to a fully specialized > format to reap even more performance benefits rather than messily patching > ELF.I dont think we should come up with another object file format. Shankar Easwaran
On Tue, Jul 30, 2013 at 8:17 PM, Shankar Easwaran <shankare at codeaurora.org>wrote:> On 7/30/2013 7:41 PM, Chandler Carruth wrote: > >> I've not been following this thread at all. However, skimming the original >> post, I fail to find a nice summary of what problem is trying to be >> solved. >> > The proposal is trying to garbage collect symbols that are not referenced > during the link step. In addition this proposal can be extended to keep > frequently called functions/data closer to increase cache coherency. > > 'lld' tries to atomize all the symbols in a section, but the problem it > faces on ELF is that, lld needs to tie all the atoms in a section together > to respect the ELF section property. This may be relaxed if lld knows at > the time of parsing the section contents, that, if you really need to tie > all the atoms together in the final ELF image. > > This proposal is just a way to convey information from the object file to > the linker that sections in the object file can be safely converted to > atoms, and they need not be tied together in whichever section they reside.OK, thanks.> > >> By reading the rest of the thread I divine that the goal is faster links >> and better dead code stripping? >> >> Making that clearer would help. Naming your sections something other than >> "safe" (which has *very* different connotations) would help more. >> > "safe" is a property of a section, by which a section can be atomized and > the atoms can appear anywhere in the final output file.I don't think that this very narrow interpretation of "safe" is going to shared by anyone who hasn't read this email from you. ;] It would need a better name, but I'm not sure we need it at all, see below.> > >> However, I question several fundamental assumptions: >> 1) We should be very certain that -ffunction-sections is not a viable >> solution as it exists and is well supported in other toolchains and >> environments. >> > -ffunction-sections and -fdata-sections would work, but that would require > all third party libraries etc to make sure that they are all compiled with > -ffunction-sections.Your proposal would require compiling all third party libraries with a compiler that supports safe sections. The goal you have is *exactly* the goal of -ffunction-sections. We don't need another mechanism to solve this problem based on the criteria you have outlined here. Your proposal is also exactly the same complexity of deployment or implementation as -ffunction-sections in that it changes the fundamental output of the toolchain to make evident the separability of the units of the code. Now, if there is a technical problem with putting functions in their own ELF sections, let's talk about that. But so far, I don't see anything even remotely compelling enough to talk about a special semantic change to certain sections. 2) We should talk to other ELF producers and coordinate to make sure we>> don't end up creating a twisty maze of extensions here. >> > This is not a problem with the general ELF community since the binutils > ld/gold would not atomize sections.Just because this won't actively explode with other ELF tools doesn't mean we shouldn't try to reach consensus throughout the larger community before changing the way in which Clang writes ELF files and LLD reads them. We really do need to maintain interoperability (by and large) with other toolchains on the same platform.> > 3) We should step back and consider leapfrogging to a fully specialized >> format to reap even more performance benefits rather than messily patching >> ELF. >> > I dont think we should come up with another object file format.OK, there are others who disagree though. =] It is at least something that we shouldn't write off and should consider *IF* we're going to also consider the rest of the proposal. But currently, I think this entire thing already works with -ffunction-sections until there is a concrete description of why that mode simply won't work.> > > Shankar Easwaran >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130731/ce3a9f71/attachment.html>
> #1 can be solved via science.I posted the numbers for -ffunction-section -fdata-section when building clang. The overhead is noticeable: 26% larger object files. The overhead of doing this with just symbols is more than just the flag itself. The assembler (MC) has to avoid resolving relocations, but that should not be as bad as 26%. Each section on ELF 64 costs 64 bytes + the name of the section. But I agree. We should do -ffunction-sections + -fdata-sections first. The format extension (flag section?) then becomes just an optimization. BTW, I do think we need more than just one flag section. If for nothing else we need to make sure we don't break __attribute__((used)). In fact, I think we will need that even for -ffunction-sections. Cheers, Rafael
>> However, I question several fundamental assumptions: >> 1) We should be very certain that -ffunction-sections is not a viable >> solution as it exists and is well supported in other toolchains and >> environments. > > -ffunction-sections and -fdata-sections would work, but that would require > all third party libraries etc to make sure that they are all compiled with > -ffunction-sections.No, just for them to be GCed. In the same way the proposals for having "safe to move symbols" would need some flags to be present in the .o files. The flags are really just an optimization.> >> 2) We should talk to other ELF producers and coordinate to make sure we >> don't end up creating a twisty maze of extensions here. > > This is not a problem with the general ELF community since the binutils > ld/gold would not atomize sections.There is no reason they could not. Cheers, Rafael