PING^3 [ARM] [1/3] Refactor NEON builtin code

[Jie Zhang]

On 01/20/2011 05:38 AM, Julian Brown wrote:
> Hi,
>
> On Mon, 17 Jan 2011 09:57:45 +0800
> Jie Zhang<jie@codesourcery.com>  wrote:
>
>>> On 12/23/2010 09:49 PM, Jie Zhang wrote:
>>>> http://gcc.gnu.org/ml/gcc-patches/2010-10/msg00851.html
>>>>
>>>> I just updated the patch to the latest trunk.
>
> I can't approve/disapprove this patch, but this part makes me nervous:
> IIUC it means that the builtins will depend on the order of patterns in
> neon.md, which seems like a potential maintenance nightmare. I think it
> also means that we depend on the order in which mode iterators get
> expanded, which I strongly suspect isn't specified anywhere.
>
> Can we avoid making that linkage?
>
Thanks for your review!

I don't think this patch will make builtins depends on the order of 
patterns in neon.md or the order of mode iterators. That patch just 
flattens neon_builtin_data[].

Before this patch, one entry in neon_builtin_data[], for example,
VAR3 (BINOP, vaddl, v8qi, v4hi, v2si) will be expanded into

{ "vaddl", NEON_BINOP, T_V8QI | T_V4HI | T_V2SI,
     { CODE_FOR_neon_vaddlv8qi,
       CODE_FOR_neon_vaddlv4hi,
       CODE_FOR_neon_vaddlv2si },
   3, 0 },

After this patch, it will be expanded into

{"vaddl", NEON_BINOP, T_V8QI, CODE_FOR_neon_vaddlv8qi, 0},
{"vaddl", NEON_BINOP, T_V4HI, CODE_FOR_neon_vaddlv4hi, 0},
{"vaddl", NEON_BINOP, T_V2SI, CODE_FOR_neon_vaddlv2si, 0},


Maybe you can be more specific?


Regards,
-- 
Jie Zhang