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

[Kevin Choi via llvm-dev]

Hi Abe,

I don't see why you couldn't make a frontend query in the pass-manager to
selectively enable such globals reordering/aligning pass. If this is a
discouraged practice noted in docs somewhere and LLVM's goal is to be truly
frontend/platform agnostic, please do correct me. AFAIK, Pass Manager
selects some optimizations based on Optimization Levels (-O2,-O3,etc), so
extending this shouldn't be a challenge.

Regards,
Kevin

Intel WOS

On 25 July 2016 at 15:36, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160725/32e9709c/attachment.html>