[PATCH 1/6][ARM] Refactor NEON builtin framework to work for other builtins

[Kyrill Tkachov]

Hi Andre,

On 09/11/16 10:11, Andre Vieira (lists) wrote:
> Hi,
>
> Refactor NEON builtin framework such that it can be used to implement
> other builtins.
>
> Is this OK for trunk?
>
> Regards,
> Andre
>
> gcc/ChangeLog
> 2016-11-09  Andre Vieira  <andre.simoesdiasvieira@arm.com>
>
>      * config/arm/arm-builtins.c (neon_builtin_datum): Rename to ..
>      (arm_builtin_datum): ... this.
>      (arm_init_neon_builtin): Rename to ...
>      (arm_init_builtin): ... this. Add a new parameters PREFIX
>      and USE_SIG_IN_NAME.
>      (arm_init_neon_builtins): Replace 'arm_init_neon_builtin' with
>      'arm_init_builtin'. Replace type 'neon_builtin_datum' with
>      'arm_builtin_datum'.
>      (arm_init_vfp_builtins): Likewise.
>      (builtin_arg): Rename enum's replacing 'NEON_ARG' with
>      'ARG_BUILTIN' and add a 'ARG_BUILTIN_NEON_MEMORY.
>      (arm_expand_neon_args): Rename to ...
>      (arm_expand_builtin_args): ... this. Rename builtin_arg
>      enum values and differentiate between ARG_BUILTIN_MEMORY
>      and ARG_BUILTIN_NEON_MEMORY.
>      (arm_expand_neon_builtin_1): Rename to ...
>      (arm_expand_builtin_1): ... this. Rename builtin_arg enum
>      values, arm_expand_builtin_args and add bool parameter NEON.
>      (arm_expand_neon_builtin): Use arm_expand_builtin_1.
>      (arm_expand_vfp_builtin): Likewise.
>      (NEON_MAX_BUILTIN_ARGS): Remove, it was unused.

  /* Expand a neon builtin.  This is also used for vfp builtins, which behave in
     the same way.  These builtins are "special" because they don't have symbolic
     constants defined per-instruction or per instruction-variant.  Instead, the
-   required info is looked up in the NEON_BUILTIN_DATA record that is passed
+   required info is looked up in the ARM_BUILTIN_DATA record that is passed
     into the function.  */
  

The comment should be updated now that it's not just NEON builtins that are expanded through this function.

  static rtx
-arm_expand_neon_builtin_1 (int fcode, tree exp, rtx target,
-			   neon_builtin_datum *d)
+arm_expand_builtin_1 (int fcode, tree exp, rtx target,
+			   arm_builtin_datum *d, bool neon)
  {

I'm not a fan of this 'neon' boolean as it can cause confusion among the users of the function
(see long thread at https://gcc.gnu.org/ml/gcc/2016-10/msg00004.html). Whether the builtin is a NEON/VFP builtin
can be distinguished from FCODE, so lets just make that bool neon a local variable and initialise it accordingly
from FCODE.

Same for:
+/* Set up a builtin.  It will use information stored in the argument struct D to
+   derive the builtin's type signature and name.  It will append the name in D
+   to the PREFIX passed and use these to create a builtin declaration that is
+   then stored in 'arm_builtin_decls' under index FCODE.  This FCODE is also
+   written back to D for future use.  If USE_SIG_IN_NAME is true the builtin's
+   name is appended with type signature information to distinguish between
+   signedness and poly.  */
  
  static void
-arm_init_neon_builtin (unsigned int fcode,
-		       neon_builtin_datum *d)
+arm_init_builtin (unsigned int fcode, arm_builtin_datum *d,
+		  const char * prefix, bool use_sig_in_name)

use_sig_in_name is dependent on FCODE so just deduce it from that locally in arm_init_builtin.

This is ok otherwise.
Thanks,
Kyrill