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

Mehdi Amini via llvm-dev llvm-dev at lists.llvm.org
Mon Jul 25 20:53:20 PDT 2016

> On Jul 25, 2016, at 3:36 PM, Abe Skolnik via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> Dear all,
> Howdy! ;-)  This is Abe of the Samsung Austin R&D Center`s compilers team.
> As an early part of a project that should help performance on some CPUs, I would like to cause global variables [at least from C and C++ programs] to be grouped together according to their alignment needs, which should help to slightly reduce RAM requirements in some cases.  IMO this should be done at "-O3" and higher levels of optimization [maybe "-O2" and higher?] and at "-Oz" [and maybe also at "-Os"].  This change is likely to break some poorly-written programs which rely on undefined behavior by assuming that consecutively-{declared/defined} global variables are allocated consecutively in RAM, so I propose to allow those programs to go on compiling to code that works as the author expected when there is no strong optimization imperative for either RAM savings or performance.
> My question this time is this: is re-ordering globals at the LLVM level both possible

Isn’t something a linker could/should do?

> [without massive rewriting of LLVM] and safe?  I don`t know whether or not it`s safe because perhaps some languages -- unlike C and C++ -- _explicitly_ allow programmers to make the assumption that consecutively-written globals at the source-code level map to consecutively-allocated globals at run-time.  If so, and if any such language is using LLVM as a back-end, then changing that behavior at the LLVM level with _any_ optimization flag may break programs that _are_ well-formed according to the rules of their respective source language[s].

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.


More information about the llvm-dev mailing list