[PATCH, ARM]: rewrite NEON vector operation intrinsics without UNSPECs

[Ramana Radhakrishnan]

Hi Sandra,

On Fri, May 28, 2010 at 6:49 PM, Sandra Loosemore
<sandra@codesourcery.com> wrote:
>
> The problem this is trying to solve is that, for some of the NEON
> instructions, there is both a pattern used by the corresponding intrinsic
> that uses an UNSPEC, and a separate canonical RTL pattern for the same
> (logically equivalent) operation.  Having two copies is a bit of a
> maintenance headache; the current patch fixes some minor differences in the
> generated code and one outright bug. Other operations currently have only
> the intrinsic pattern with an UNSPEC, which means that GCC will never emit
> those instructions any other way.

 Could you mention what bug this patch particularly solves and if this
occurs in any of the FSF release branches or on trunk ? Is there a
possibility of splitting out the bug fix into a separate patch that
could potentially be backported to other release branches ?

>
> There's a little "gotcha" involved in merging some of the patterns in the
> first category:  in some cases the canonical RTL may not expand into the
> exact NEON instruction as the intrinsic implies.  A good example of this is
> some of the "move" patterns:  if the source is not in a NEON register to
> begin with, it makes little sense to move it to one just so we can use a
> NEON instruction to move it someplace else.  ARM's specification of the
> intrinsics does not require use of the exact NEON instruction, but GCC's
> auto-generated testcases do make that requirement unless you explicitly
> disable it.  So, for the affected intrinsics, I've both turned off the code
> generation check and added a new execution test that checks for the expected
> runtime behavior.


I would agree that there is no requirement for the intrinsics to map
to the exact Neon instruction and thus the idea of adding more
execution tests for the Neon intrinsics and the checks for the
expected run-time behaviour makes sense. Longer term I would like us
to move towards having more run time tests for the Neon intrinsics
than what is currently the case.

>
> These changes have been in our local tree for a while and I just retested
> this version of the patch in an arm-none-eabi build with simulator testing
> for both NEON and non-NEON compilation options.  OK to check in?
>

I haven't had the time to go through the patch in its entirety yet,
but from a cursory glance at the it I see endian-dependent changes in
the sources. Do you think it's worthwhile to run the testsuite in big
endian mode for this with Neon ?

cheers
Ramana