Hi Michael,
On 24/02/16 23:02, Michael Collison wrote:
This patch adds support for builtin overflow of add, subtract and negate. This
patch is targeted for gcc 7 stage 1. It was tested with no regressions in arm
and thumb modes on the following targets:
arm-non-linux-gnueabi
arm-non-linux-gnuabihf
armeb-none-linux-gnuabihf
arm-non-eabi
I'll have a deeper look once we're closer to GCC 7 development.
I've got a few comments in the meantime.
2016-02-24 Michael Collison <michael.colli...@arm.com>
* config/arm/arm-modes.def: Add new condition code mode CC_V
to represent the overflow bit.
* config/arm/arm.c (maybe_get_arm_condition_code):
Add support for CC_Vmode.
* config/arm/arm.md (addv<mode>4, add<mode>3_compareV,
addsi3_compareV_upper): New patterns to support signed
builtin overflow add operations.
(uaddv<mode>4, add<mode>3_compareC, addsi3_compareV_upper):
New patterns to support unsigned builtin add overflow operations.
(subv<mode>4, sub<mode>3_compare1): New patterns to support signed
builtin overflow subtract operations,
(usubv<mode>4): New patterns to support unsigned builtin subtract
overflow operations.
(negvsi3, negvdi3, negdi2_compre, negsi2_carryin_compare): New patterns
to support builtin overflow negate operations.
Can you please summarise what sequences are generated for these operations, and
how
they are better than the default fallback sequences.
Also, we'd need tests for each of these overflow operations, since these are
pretty complex
patterns that are being added.
Also, you may want to consider splitting this into a patch series, each adding
a single
overflow operation, together with its tests. That way it will be easier to keep
track of
which pattern applies to which use case and they can go in independently of
each other.
+(define_expand "uaddv<mode>4"
+ [(match_operand:SIDI 0 "register_operand")
+ (match_operand:SIDI 1 "register_operand")
+ (match_operand:SIDI 2 "register_operand")
+ (match_operand 3 "")]
+ "TARGET_ARM"
+{
+ emit_insn (gen_add<mode>3_compareC (operands[0], operands[1], operands[2]));
+
+ rtx x;
+ x = gen_rtx_NE (VOIDmode, gen_rtx_REG (CC_Cmode, CC_REGNUM), const0_rtx);
+ x = gen_rtx_IF_THEN_ELSE (VOIDmode, x,
+ gen_rtx_LABEL_REF (VOIDmode, operands[3]),
+ pc_rtx);
+ emit_jump_insn (gen_rtx_SET (pc_rtx, x));
+ DONE;
+})
+
I notice this and many other patterns in this patch are guarded on TARGET_ARM.
Is there any reason why they
should be restricted to arm state and not be TARGET_32BIT ?
Thanks,
Kyrill
