[PATCH] Rewrite arm_neon.h generation from scratch

James Molloy james.molloy at arm.com
Wed Jun 11 03:40:52 PDT 2014


Hi Renato,

Sorry, I just realised I didn't actually answer your question.

> On the patches, the SetTheory files are new, but there are no deleted
> files. Are you moving, or just copying?

Potentially there has been a git SNAFU. The intention is to move SetTheory, removing the old files (and updating CMakeLists.txt, as Jiangning mentioned). I have a horrible feeling I didn't merge a fixup commit into the main commit and just sent the main commit without the fixup...

Either way, It's trivial and you get the idea of the patch.

James

> -----Original Message-----
> From: Renato Golin [mailto:renato.golin at linaro.org]
> Sent: 05 June 2014 21:32
> To: James Molloy
> Cc: Clang Commits; Tim Northover; Jiangning Liu; Hao Liu; Amara Emerson;
> Jim Grosbach
> Subject: Re: [PATCH] Rewrite arm_neon.h generation from scratch
> 
> On 4 June 2014 11:39, James Molloy <james.molloy at arm.com> wrote:
> > Here's an example: before:
> >
> >   case OpAbdl: {
> >     std::string abd = MangleName("vabd", typestr, ClassS) + "(__a,
> __b)";
> >     if (typestr[0] != 'U') {
> >       // vabd results are always unsigned and must be zero-extended.
> >       std::string utype = "U" + typestr.str();
> >       s += "(" + TypeString(proto[0], typestr) + ")";
> >       abd = "(" + TypeString('d', utype) + ")" + abd;
> >       s += Extend(utype, abd) + ";";
> >     } else {
> >       s += Extend(typestr, abd) + ";";
> >     }
> >     break;
> >   }
> >
> > after:
> >
> >   def OP_ABDL     : Op<(cast "R", (call "vmovl", (cast $p0, "U",
> >                                                        (call "vabd",
> $p0,
> > $p1))))>;
> 
> Shut up and take my money!
> 
> On the patches, the SetTheory files are new, but there are no deleted
> files. Are you moving, or just copying?
> 
> Also, the other patch seems a much cleaner TableGen file, but the C++
> file got completely messed up by patch thinking that close function
> curly brackets is "equal" no matter which function they belong. You'd
> think that after several decades using diff for patch review they
> would begin to understand the concept of functions, structures, etc.
> 
> Anyway, I like the idea and I think it's an important move. I'm not
> too bothered about the weird test cases, as long as the remaining ones
> have a similar coverage.
> 
> cheers,
> -renato








More information about the cfe-commits mailing list