[cfe-dev] Illegal vector type replacement for ARM

[Tim Northover]

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.

Cheers.

Tim.