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.simoesdiasvie...@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
