[llvm-commits] [llvm] r140902 - in /llvm/trunk: lib/CodeGen/SelectionDAG/SelectionDAG.cpp test/CodeGen/X86/alignment-2.ll

[Duncan Sands]

Hi Bill,

>>>>> When inferring the pointer alignment, if the global doesn't have an initializer
>>>>> and the alignment is 0 (i.e., it's defined globally in one file and declared in
>>>>> another file) it could get an alignment which is larger than the ABI allows for
>>>>> that type, resulting in aligned moves being used for unaligned loads.
>>>>
>>>> even if it has an initializer that doesn't mean anything if the global has a
>>>> weak linkage type since in the final program a different initializer might be
>>>> used.  In short, the code a line or so above should use hasDefinitiveInitializer
>>>> not hasInitializer.
>>>>
>>> Does that matter in this case? It's just trying to see if there's a preferred alignment, which from what I can tell relies upon the type and not the initializer. If I read this correctly, the presence of an initializer is what's important here.
>>
>> the type could be different in a different translation unit, so yes it
>> does matter.
>>
> Really? That sounds like a bug. If it changes the type from, say, a scalar to a vector, that's not good...

don't forget that the other compilation unit may have been compiled using a
different compiler.  Even if the type is the same, the other compiler is free
to use the ABI alignment rather than something better like LLVM's preferred
alignment.  I think this applies to C++ types too in spite of the ODR: since
the ABI only mandates ABI alignment, if it is the definition compiled by the
other compiler that ends up being used in the final executable then only the
ABI alignment can be assumed.  That means that I was wrong to suggest using
hasDefinitiveInitializer.  Instead I think the check should be that the linkage
satisfies !isWeakForLinker, i.e. that the memory allocated for the global by
LLVM is what will actually be used in the final program.

Ciao, Duncan.