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

Rafael EspĂ­ndola via llvm-commits llvm-commits at lists.llvm.org
Tue Apr 4 15:02:03 PDT 2017


On 4 April 2017 at 17:52, Tobias Edler von Koch <tobias at codeaurora.org> wrote:
> On 04/04/2017 04:48 PM, Rafael EspĂ­ndola wrote:
>>
>> My view is that we are changing include/llvm/IR/Module.h instead of
>> having them fix their code. No one should ever depend on an IR
>> property not specified in the langref and this feels like a slippery
>> slope.
>
>
> Well, it's a utility function that you created by factoring out the code we
> originally discussed here; it currently only has two uses, both in LTO. BTW
> I don't disagree with the refactoring at all, just wanted to point out it's
> not some widely used common code I'm touching.
>
> I'd also like to point out that my main concern at this point is not
> resisting to tell our customers to change their code (they will do that in
> due course), but the unpredictable performance variations between LTO and
> non-LTO this introduces - even at -O0.

If that is you real concern, you should change the asm printer to
implement an heuristic. It is the one that is deciding what order
thing should go in the .o file. The order in the IR is not guaranteed
to have *any* relation to the order in the .o file.

Can you explain why one order is better than the other? Do you have a
benchmark we can reproduce?

Cheers,
Rafael


More information about the llvm-commits mailing list