[llvm] r190636 - Fix PPC ABI for ByVal structs with vector members
Ulrich Weigand
Ulrich.Weigand at de.ibm.com
Fri Feb 27 16:14:41 PST 2015
Hal Finkel <hfinkel at anl.gov> wrote on 28.02.2015 00:41:39:
> and so we always get the alignment correct, because it is the
> alignment if 'i128' (which is 16). To digress slightly, I'm now
> somewhat concerned that this works more-or-less by accident (because
> DataLayout only defaults to giving natural alignment to vector
> types, for integers we normally just take the largest integer
> alignment specified, which would be 8 in this case, and for arrays
> we take the alignment of the element type) but all of the
> temporaries have 16 byte alignment, and so it happens to do the
> right thing (Uli implemented this, so I'm cc'ing him here).
So the way I intended this to work is that clang specifies the
expected alignment in the argument save area by the *size* of
the array element type (i.e. aggregates that require 8-byte
alignment are passed as arrays of i64, and aggregates that
require 16-byte alignment as passed as arrays of i128).
In LLVM we respect that request by looking at the *size* of the
array element type in CalculateStackSlotAlignment:
// Array members are always packed to their original alignment.
if (Flags.isInConsecutiveRegs()) {
// If the array member was split into multiple registers, the first
// needs to be aligned to the size of the full type. (Except for
// ppcf128, which is only aligned as its f64 components.)
if (Flags.isSplit() && OrigVT != MVT::ppcf128)
Align = OrigVT.getStoreSize();
else
Align = ArgVT.getStoreSize();
}
The important bit is the "OrigVT.getStoreSize" here, which will
be 128 for an array of i128.
This may be a bit nonintuitive, but it was the only way I found to
pass alignment information from clang to LLVM if I didn't want to
use ByVal.
I did extensive testing (in particular, using GCC's foreign compiler
ABI test suite to make sure GCC and LLVM are interoperable), so I
don't think it works just by accident :-)
Bye,
Ulrich
More information about the llvm-commits
mailing list