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

[Philip Reames via llvm-dev]

I do not believe that we guarantee any order of globals.  Unless someone else points out a case where we do, we should not intro extra complexity to provide a choice here.  

You may want to take a look an unnamed_addr flag on globals.  It may be relevant here.  (*may*)

Philip



> 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 [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].
> 
> Regards,
> 
> Abe
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev