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

[Bill Wendling]

On Oct 2, 2011, at 5:10 AM, John McCall wrote:

> On Oct 2, 2011, at 3:26 AM, Duncan Sands wrote:
>> 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.

Okay, yes. I was just worried when you said that the types could change. The fundamental representation of the type doesn't change. I.e., "this object is X-bytes long and has an (ABI) alignment of A."

>> 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.
> 
> There are two possible interpretations for alignment on a weak global:
>  (a) the minimum guaranteed alignment, which all emissions must satisfy, or
>  (b) the alignment to use for this emission, which can be higher.
> The value of expressing (b) is to enable runtime optimizations:  we can never assume statically that the global is (say) 16-byte aligned, but if it is (more likely the more individual emissions we over-align), things get faster.  But otherwise it's pretty useless;  nothing in the compiler cares except object emission.  For everyone's sake, the usual alignment computation clearly needs to compute (a), not (b).
> 
> I don't think it's a good idea to change the usual alignment computation for this case, either.  As it is, it's very nice and regular:  use explicit alignment if present, otherwise use the ABI alignment of the IR type.
> 
> So I would argue that this all means that frontends have the responsibility to ensure that the usual alignment computation doesn't yield something "optimistic".  I think we really don't want the optimizers and the backend to be in the business of second-guessing that.  Recall that the major source languages have ways to raise and (frequently) lower the minimum guaranteed alignment for specific declarations.
> 
FWIW, I concur.

-bw