<div dir="ltr">Hi Peter,<div><br></div><div><div class="gmail_quote"><div dir="ltr">On Mon, May 14, 2018 at 8:14 AM Peter Smith via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
My understanding from the RFC is:<br>
- All global objects in the bitcode file will be assigned a section name.<br></blockquote><div><br></div><div>... which is equal to the section name that they would have been emitted to if this was a regular compilation. In addition to allowing the linker to read section names from the bitcode, this also helps support mixing -ffunction-sections and -fno-function-sections and similar options (forgot to mention that in the RFC).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- A linker will communicate the output section of all global objects.</blockquote><div><br></div><div>Correct. (Global objects in the LLVM sense, so that includes objects with local linkage).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Certain transformations won't be performed if the output section is different.<br></blockquote><div><br></div><div>Correct. Plus, others can be enabled if they're safe to apply when we know things are going to the same output section.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The common use cases that I can see that might not fit perfectly into<br>
that model:<br>
- Code that is in different OutputSections but it will be logically<br>
correct and in many cases desirable to perform transformations on as<br>
if they were in the same output section.</blockquote><div><br></div><div>Right. The output section that the linker communicates for a symbol doesn't need to correspond to a "physical" output section. So let's say if the linker knows (or the user somehow tells it) that two output sections should be considered equivalent, the linker can communicate the same output section identifier for symbols in either of the two physical output sections. This is perfectly safe since the output section info is only ever used to enable/inhibit optimizations, not for actual symbol emission by LTO.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Output section placement rules that are not based on names, for<br>
example Arm's linker can assign sections to an output section until<br>
the output section size limit is reached, then a different output<br>
section is used. I admit that this may be more of a problem for<br>
linkers that have a different linker script model.<br></blockquote><div><br></div><div>That should actually just work in the existing model. Before LTO runs, we don't know the size of symbols anyway, so the linker will just communicate the original output section for all of them and we apply optimizations across them as if they all fitted in the same section. After LTO, some may end up in the 'overflow' section but LTO doesn't need to know about that since it wouldn't have been correct for the user to make any assumptions about what ends up in the original section vs overflow in the first place.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think both cases are illustrative of a use case where the precise<br>
output section does not matter, but there is a vaguer goal of placing<br>
a subset of the input sections in a subset of the output sections.<br>
>From what I can tell there isn't a way for the code generator to tell<br>
the difference between code that is placed in different output<br>
sections and it is not correct or beneficial to optimize and code that<br>
is placed in different output sections and it is correct and<br>
beneficial to optimize together.<br></blockquote><div><br></div><div>Perhaps we should rename the "output section" that is communicated to LTO to something less specific to make it clear that it can be used for exactly this purpose. Optimization domain? Partition?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think that this kind of use case could be supported by doing something like:<br>
- Linker informs code generator the output sections that must not use<br>
any information from another module and may not contribute any<br>
information to another module. For example an output section that is<br>
representing an overlay.<br></blockquote><div><br></div><div>It's not so much about other modules (files) - you could have multiple files contributing input sections to the same overlay, for instance, and you would want to optimize across them. But you wouldn't want to de-duplicate a constant from another overlay. I think the OutputSectionID-as-optimization-domain idea captures this use case, no?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- Linker can omit the output section information for sections that the<br>
user doesn't care where they go, and let the linker decide based on<br>
some size constraint later. </blockquote><div><br></div><div>That's an interesting idea to allow a 'don't care' output section ID; we would have to be pretty careful in defining what that means on a per-optimization basis. That is, am I allowed to inline a function with a defined output section into a function without one (probably no)? Vice versa (probably yes)?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think that these are mostly details rather than fundamental problems though.<br></blockquote><div><br></div><div>Thank you very much for your comments!</div><div><br></div><div>Tobias</div></div></div></div>