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.