[PATCH] [ARM] Align global variables passed to memory intrinsics
John Brawn
john.brawn at arm.com
Tue Mar 24 07:45:24 PDT 2015
REPOSITORY
rL LLVM
================
Comment at: lib/CodeGen/CodeGenPrepare.cpp:1249
@@ -1248,1 +1248,3 @@
+ if ((Offset2 & (PrefAlign-1)) != 0)
+ continue;
AllocaInst *AI;
----------------
hfinkel wrote:
> If you add a continue here, then you might end up skipping some logic further down that would otherwise apply, no?
>
That's what we want: this is the 'offset must be a multiple of the alignment' check, and if it's not true we don't want to align for both allocas and global variables.
================
Comment at: lib/CodeGen/CodeGenPrepare.cpp:1257
@@ +1256,3 @@
+ // object (they have an initializer), and over-aligning global variables
+ // that have an explicit section is forbidden.
+ GlobalVariable *GV;
----------------
hfinkel wrote:
> Why? Do the alignments need to match?
http://llvm.org/docs/LangRef.html#global-variables says:
Targets and optimizers are not allowed to over-align the global if the global has an assigned section. In this case, the extra alignment could be observable: for example, code could assume that the globals are densely packed in their section and try to iterate over them as an array, alignment padding would break this iteration.
================
Comment at: lib/CodeGen/CodeGenPrepare.cpp:1260
@@ +1259,3 @@
+ if ((GV = dyn_cast<GlobalVariable>(Val)) &&
+ GV->hasInitializer() &&
+ !GV->hasSection() &&
----------------
hfinkel wrote:
> Do you want this or hasUniqueInitializer() or hasDefinitiveInitializer()?
>
I //think// that hasUniqueInitializer is what we want. We want to make sure that increasing the alignment of this GlobalVariable will definitely increase the alignment in the final executable, i.e. we won't get a definition of this variable from another object that doesn't have this increased alignment.
http://reviews.llvm.org/D8421
EMAIL PREFERENCES
http://reviews.llvm.org/settings/panel/emailpreferences/
More information about the llvm-commits
mailing list