This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, ARM] Don't force vget_lane returning a 64-bit result to transfer to core registers
- From: Julian Brown <julian at codesourcery dot com>
- To: Richard Earnshaw <rearnsha at arm dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 23 Mar 2012 09:53:27 +0000
- Subject: Re: [PATCH, ARM] Don't force vget_lane returning a 64-bit result to transfer to core registers
- References: <4F69B96D.7010108@arm.com>
On Wed, 21 Mar 2012 11:20:13 +0000
Richard Earnshaw <rearnsha@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