[cfe-dev] Illegal vector type replacement for ARM

[Stephen Hines]

On Tue, Jan 15, 2013 at 11:45 PM, Tim Northover <t.p.northover at gmail.com>wrote:

> Hi Stephen,
>
> Chucking in my tuppence,
>
> > If compiled for ARMv7, the <3 x i64> parameter will become a <3 x i64>*
> > indirect parameter.
>
> This is odd from an AAPCS view. Every other type (except where
> required to obey C++ semantics) gets passed directly in ARM. I can't
> really see any justification for the pointer and would support
> reverting this part.
>
> > The second major difference that I noticed (also in my sample file) was
> that
> > that we are now losing semantic information about the incoming arguments
> to
> > a function with a vector parameter that requires less than 32 bits of
> > storage space (like <2 x i8>, <3 x i8>). In these cases, they are being
> > explicitly coerced to a single i32 parameter, which is later used in the
> > function body to extract the individual vector components.
>
> Whether by coincidence or not, I believe i32 is the only justifiable
> way to pass that type (unless you decide it gets promoted to an <8 x
> i8> and goes in vector registers, which also loses size information).
>
> In particular, using i16 is incorrect in the big-endian case. For
> example, passing the following object in big-endian:
>
> struct { char c1, c2; } my_obj = {1, 2};
>
> needs to result in r0 = 0x01020000, which is not a valid i16.
>
>
I am not actually advocating a switch to i16 here. I actually do suggest
keeping the original <2 x i8> so that the type/size is preserved
completely. This makes it more consistent with the other vector types and
provides greater flexibility for other bitcode consumers. It also keeps the
ABI consistent with the previous 3.x releases of LLVM, which is something I
thought we were really striving for.

Steve


> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130115/a0441203/attachment.html>