[PATCH] D31443: [LTO] Do not reorder global variables unnecessarily during merging

Tobias Edler von Koch via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 3 11:59:39 PDT 2017


On 03/29/2017 01:25 PM, Mehdi Amini wrote:
>> the wrong precedence. The output is not defined to be in any specified
>> order.
>
> I sympathize with this, and I’m OK with this change only because it is 
> going from a random order to another, with a 3 lines change. Anyone 
> having a reason to change it to another order (i.e. not random) should 
> be free to do so and not be locked by this change.

I'm happy to modify the comments to make it clear that this doesn't 
establish such a precedent. I think we all agree we don't want to 
enforce this in any way. But absent a better way of laying out data 
based on PGO, not changing the source order here - like we have always 
done in the past - is the best we can do. I feel this is what Gerolf's 
and Tim's comments imply also.

>
>> Anything trying to optimize the order should operate at a level
>> lower than llvm IR.
>
> I think an LTO IR Pass that operate at the IR level should be OK as 
> well. What’s wrong with that? It’s much more friendly than lower level 
> (binary…) and better integrated with things like PGO. Also it makes 
> the optimization independent of the linker.
> I’m not saying it is wrong to do it at the linker level as well, but I 
> don’t see a problem with such an IR pass.

So this is a bit of an aside but I can think of a couple of reasons why 
it's not ideal to do layout on LLVM IR:
1) Linker scripts (I can hear you laugh... :)) - you essentially don't 
know which output sections things will eventually end up in and in which 
order until you're at the link stage.
2) Even without linker scripts, data is pulled apart into multiple 
sections (.data, .bss). Hexagon (and others) also have GP-relative 
addressing modes, so some small data will go to .sdata and .sbss. This 
is only known in the backend, past IR.
3) It won't work for ThinLTO because files are still essentially 
compiled individually so we don't have a way to reorder things globally 
(without moving globals between files).

Tobias

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170403/02e2547e/attachment.html>


More information about the llvm-commits mailing list