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

Than McIntosh via llvm-dev llvm-dev at lists.llvm.org
Tue Aug 9 06:38:54 PDT 2016

Arriving late to this thread, but to add what others have said: reordering
or sorting data items based on alignment is straightforward to do in a
linker plugin. An example can be found in this test (part of gold linker
test suite):


The source for the plugin is at



On Tue, Jul 26, 2016 at 12:54 PM, Mehdi Amini via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> > 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160809/08a95f1e/attachment.html>

More information about the llvm-dev mailing list