[cfe-dev] Illegal vector type replacement for ARM

[Manman Ren]

On Jan 15, 2013, at 11:45 PM, Tim Northover 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.
We can try to match how back-end legalizes these or try to legalize them in front-end by increasing the number of elements.

Thanks,
Manman
> 
>> 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.
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev