This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [testsuite] require arm_little_endian in two tests


On 14/10/11 16:21, Joseph S. Myers wrote:
> On Fri, 14 Oct 2011, Richard Earnshaw wrote:
> 
>> One way we might address this is to redefine our 128-bit vector types as
>> structs of low/high Dwords.  Each Dword remains a vector (apart from
>> 64-bit lane types), but the Dword order then matches the ABI
>> specification correctly.  For example, the definition of uint8x16_t becomes
>>
>> 	typedef struct { uint8x8_t _val[2]; } uint8x16_t;
> 
> Those types have different ABIs for argument passing and return, so you'd 
> need some magic for special handling of the uint8x16_t type as defined in 
> the header....
> 

Yes, it's not a simple substitution, but it more correctly describes the
data type that the architecture supports.  It might be necessary to
create a special internal type to distinguish it from user types that
are equivalent.


>> Secondly, all vector loads/stores should really be changed to use
>> vld1.64 (with {d<n>, d<n+1>} as the register list for 128-bit accesses)
>> rather than vldm; this then sorts out any issues with unaligned accesses
>> without changing the memory format.
> 
> vld1 runs into problems for big-endian of not being able to do core 
> register loads / stores / transfers between core and NEON registers that 
> way, and needing to convert to the other format for argument passing / 
> return.
> 

Note that I said vld1.64 (not vld1.<lane-size>.  That has the same
memory format as vldm, except that it can also deal with unaligned accesses.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]