On Wed, 21 Mar 2012 11:20:13 +0000
Richard Earnshaw <rearn...@arm.com> wrote:
> Semantically the neon intrinsic vgetq_lane_[su]64 returns a 64 bit
> sub-object of a 128-bit vector; there's no real need for the intrinsic
> to map onto a specific machine instruction.
> Indeed, if force a particular instruction that moves the result into a
> core register, but then want to use the result in the vector unit, we
> don't really want to have to move the result back to the other
> register bank. However, that's what we do today.
> This patch changes the way we expand these operations so that we
> no-longer force selection of the get-lane operation.
> A side effect of this change is that we now spit out the fmrrd
> mnemonic rather than the vmov equivalent. As a consequence I've
> updated the testsuite to allow for this change. The changes to the
> ML files are pretty mechanical, but I don't speak ML so it would be
> helpful if another pair of eyes could check that bit over and tell me
> if I've missed something subtle.
The Ocaml bits look fine to me (the compiler won't accept incorrect
programs, as I'm sure you've noticed ;-)).
> Tested on trunk and gcc-4.7, but only installed on trunk.
Don't forget to check big-endian mode too...