This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] ARM cmpsi2_addneg fixes (PR target/89506)
- From: Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Kyrill Tkachov <kyrylo dot tkachov at foss dot arm dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, nd <nd at arm dot com>
- Date: Fri, 1 Mar 2019 15:41:33 +0000
- Subject: Re: [PATCH] ARM cmpsi2_addneg fixes (PR target/89506)
- References: <DB5PR08MB1030B0A5E2D0209E43C7F35283760@DB5PR08MB1030.eurprd08.prod.outlook.com>,<20190301150748.GQ7611@tucnak>
Hi Jakub,
>> This is overcomplicating something simple - adds/subs are completely
>> symmetrical on all Arm targets. So for addition you simply place adds
>> alternative first and then subs. For comparison/subtraction place the
>
> As I wrote, that is what I have done,
That's not what your proposed patch does:
- "TARGET_32BIT && INTVAL (operands[2]) == -INTVAL (operands[3])"
- "@
- adds%?\\t%0, %1, %3
- subs%?\\t%0, %1, #%n3"
+ "TARGET_32BIT
+ && (INTVAL (operands[2])
+ == trunc_int_for_mode (-INTVAL (operands[3]), SImode))"
+{
+ /* For 0 and INT_MIN it is essential that we use subs, as adds
+ will result in different condition codes (like cmn rather than
+ like cmp). For other immediates, we should choose whatever
+ will have smaller encoding. */
+ if (operands[2] == const0_rtx
+ || INTVAL (operands[2]) == -HOST_WIDE_INT_C (0x80000000)
+ || which_alternative == 1)
+ return "subs%?\\t%0, %1, #%n3";
+ else
+ return "adds%?\\t%0, %1, %3";
+}
Adds/subs were in the incorrect order before and should simply be swapped
rather than replaced by complex C code (which would be unique just to this pattern
when there are lot of similar patterns that do the right thing already).
> and regtest revealed two code size
> regressions because of that. Is -1 vs. 1 the only case of immediate
> valid for both "I" and "L" constraints where the former is longer than the
> latter?
Yes -1 is the only case which can result in larger code on Thumb-2, so -1 should
be disallowed by the I constraint (or even better, the underlying query). That way
it will work correctly for all add/sub patterns, not just this one.
Wilco