Matt Arsenault via llvm-dev
2016-Jul-26 17:02 UTC
[llvm-dev] grouping global variables by alignment: safe to do at LLVM level, or only at Clang level?
> On Jul 25, 2016, at 20:53, Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > Isn’t something a linker could/should do?We have a problem where some globals are lowered to an immediate address in the DAG. It would be nice if we had some fixed order for the globals before then. Right now the total allocated size at the end depends on the use order, block by block, inverse within the block -Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160726/32ca04ce/attachment.html>
Abe Skolnik via llvm-dev
2016-Jul-26 17:27 UTC
[llvm-dev] grouping global variables by alignment: safe to do at LLVM level, or only at Clang level?
On 07/26/2016 12:02 PM, Matt Arsenault wrote:> We have a problem where some globals are lowered to an immediate address in the DAG.My apologies, but I don`t think I really understood that statement. Could anybody please expand/explain? Regards, Abe
Matt Arsenault via llvm-dev
2016-Jul-31 07:19 UTC
[llvm-dev] grouping global variables by alignment: safe to do at LLVM level, or only at Clang level?
> On Jul 26, 2016, at 10:27, Abe Skolnik <a.skolnik at samsung.com> wrote: > > On 07/26/2016 12:02 PM, Matt Arsenault wrote: > >> We have a problem where some globals are lowered to an immediate address in the DAG. > > My apologies, but I don`t think I really understood that statement. Could anybody please expand/explain? > > Regards, > > AbeThe first allocated global has address 0. If a 16 byte object is allocated, the next object’s address will be the constant 16 -Matt
Apparently Analagous Threads
- grouping global variables by alignment: safe to do at LLVM level, or only at Clang level?
- grouping global variables by alignment: safe to do at LLVM level, or only at Clang level?
- grouping global variables by alignment: safe to do at LLVM level, or only at Clang level?
- defaults for FP contraction [e.g. fused multiply-add]: suggestion and patch to be slightly more aggressive and to make Clang`s optimization settings closer to having the same meaning as when they are given to GCC [at least for "-O3"]
- [cfe-dev] improving test-suite`s FP subtests to be able to compare both exact-match outputs and more-optimized builds that may have different outputs due to FP optimizations