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... Cheers, Julian
