[PATCH] AARCH64_BE load/store rules fix for ARM ABI
akadlec at a-bix.com
Fri Mar 7 02:11:38 PST 2014
Just a short comment since I don't work for Abix any more (due to differences in promised/actual payment) -> Christian, the other compiler guy at Abix will probably pick this up shortly.
alignment is a minimum-attribute of a type. The type can always be better-aligned, and
1) there's a tendency to do that for many chips to better utilize memory bus cycles.
2) unioning with a 128bit int will boost a vector's alignment (although you get lucky now in that it's not an HVA any more) -> Any such boost in alignment would suddenly have it stored in a different format (STR). Giving the address of the vector to a function has the function not knowing the actual alignment *) -> it will assume minimum alignment and load via LD1 - unless we have a clean type-separation between HVAs and array-like aggregates.
*) pointer-to-T args have to demote alignemnt to the minimum alignment of T, as its' sufficient that any passed argument might be aligned that low.
The bad example may not work exactly like this, but it's bound to be found eventually.
For me, relying on alignment alone is just asking for disaster:
It's not inconceivable, that someone might write an alignment analysis that tries to supply better-than guaranteed-for-the-type alignment to the backend in order to exploit aligned loads with lower memory bus resource usage (e.g. malloc/new -ed variables are typically 128bit aligned anyway).
For AARCH64 it might not be a bad idea to boost alignment for types similar to vector types anyway, if you want to get performance out of NEON (actually, I think that's what ARM tried to achieve with that definition).
It would be very strange to enforce higher alignment for HVAs and force array-type data to lower alignment, when LD1 also benefits from higher alignment.
The frontend must give the backend a totally different type for short vectors (HVAs), so that the memory layouts cannot be mixed.
Then you can re-eanble LD1 for array type loads in BE.
More information about the llvm-commits