Re: [Patch ARM 1/3] Neon intrinsics TLC : Replace intrinsics with GNU C implementations where possible.

[Richard Earnshaw <rearnsha at arm dot com>]

On 28/04/14 14:01, Ramana Radhakrishnan wrote:
> 
> On Mon, Apr 28, 2014 at 12:44 PM, Julian Brown <julian@codesourcery.com> 
> wrote:
>  > On Mon, 28 Apr 2014 11:44:01 +0100
>  > Ramana Radhakrishnan <ramrad01@arm.com> wrote:
>  >
>  >> I've special cased the ffast-math case for the _f32 intrinsics to
>  >> prevent the auto-vectorizer from coming along and vectorizing addv2sf
>  >> and addv4sf type operations which we don't want to happen by default.
>  >> Patch 1/3 causes apparent "regressions" in the rather ineffective
>  >> neon intrinsics tests that we currently carry soon hopefully to be
>  >> replaced by Christophe Lyon's rewrite that is being reviewed. On the
>  >> whole I deem this patch stack to be safe to go in if necessary. These
>  >> "regressions" are for -O0 with the vbic and vorn intrinsics which
>  >> don't now get combined and well, so be it.
>  >
>  > I think reimplementing these intrinsics in C is a mistake if we ever
>  > hope to make big-endian mode work properly, and "fixing" the generated
>  > header file by bypassing the generator makes it harder to accurately
>  > perform the sweeping changes that will probably be necessary to do that.#
> 
> 
>  > Recall e.g. the discussion around:
> 
>  >
>  > http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00161.html
> 
> Well, it would help if the generator were written in a better language 
> than ML :) . While I don't mind the different language in the backend 
> once in a while the problem is that everytime anyone needs to make a 
> change to this file, we spend far more time relearning ML than actually 
> doing the change :(.
> 

I agree: it's time the ML files went.  They're an impediment to
maintenance these days.

When the ML description was added it did three things: generated
arm_neon.h, generated the testsuite and generated a pipeline description
for Cortex-A8.  As we've progressed the second and third of these have
gone away (or at least, are about to in the case of the testsuite),
leaving only the arm_neon.h generation.  I don't see any real merit in
having that file generated from the ML file; we might as well just
maintain the existing code directly and that brings about the chance to
have more people actively work on fixing issues there without having to
learn ML first.

R.