[llvm-dev] grouping global variables by alignment: safe to do at LLVM level, or only at Clang level?

[Mehdi Amini via llvm-dev]

> On Jul 26, 2016, at 8:46 AM, Abe Skolnik <a.skolnik at samsung.com> wrote:
> 
>>> My question this time is this: is re-ordering globals at the LLVM level both possible [...]
> 
> On 07/25/2016 10:53 PM, Mehdi Amini wrote:
> 
>> Isn’t something a linker could/should do?
> 
> AFAIK & TTBOMK, a compiler should do it [if allowed by the language]

Compiler only see one translation unit at a time, the linker sees multiple, it is not clear to me why you are thinking the compiler should handle it?

> and a linker should not mess it up.  I don`t know that a linker is allowed to make assumptions about code not traversing labels in its data accesses.  After all, a compiler may have assigned labels to e.g. the start of a "struct" instance and to a specific part of that same struct.  That doesn`t mean the linker is free to move the middle of the struct somewhere else far from the start of the struct.
> 
> IOW, a linker is required to handle the code no matter what the source language was and what its specification says about implementations being allowed to re-order things and whether or not the language allows the programmer to _validly_ assume that when two arrays of identical element type are created back-to-back, the second array immediately follows the first, thus effectively creating a single array with its element count being the sum of the two element counts of the as-written arrays.
> 
> 
> 
> On 07/25/2016 10:53 PM, Mehdi Amini wrote:
> 
>> Such programming language should not use LLVM global variables if they need to provide such guarantee,
>> but probably use instead something more like a global array when lowering to LLVM IR.
> 
> Agreed, but I can`t [en]force that.  That would need to be decided by the LLVM steering committee or something like that, then documented publicly.

I’m saying that it is *already* the current state of affairs, AFAIK we don’t provide any guarantee about what you describes.

— 
Mehdi