public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH][ARM][2/4] Fix operand costing logic for SMUL[TB][TB]
@ 2016-01-22  9:52 Kyrill Tkachov
  2016-02-04  9:00 ` Ramana Radhakrishnan
  0 siblings, 1 reply; 4+ messages in thread
From: Kyrill Tkachov @ 2016-01-22  9:52 UTC (permalink / raw)
  To: GCC Patches; +Cc: Ramana Radhakrishnan, Richard Earnshaw, Jim Wilson

[-- Attachment #1: Type: text/plain, Size: 741 bytes --]

Hi all,

As part of investigating the codegen effects of a fix for PR 65932 I found we assign
too high a cost for the sign-extending multiply instruction SMULBB.
This is because we add the cost of a multiply-extend but then also recurse into the
SIGN_EXTEND sub-expressions rather than the registers (or subregs) being sign-extended.

This patch is a simple fix. The fix is right by itself, but in combination with patch 3
fix the gcc.target/arm/wmul-2.c testcase.

Bootstrapped and tested on arm-none-linux-gnueabihf.

Ok for trunk?

Thanks,
Kyrill

2016-01-22  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>

     * config/arm/arm.c (arm_new_rtx_costs, MULT case): Properly extract
     the operands of the SIGN_EXTENDs from a SMUL[TB][TB] rtx.

[-- Attachment #2: arm-smulbb-costs.patch --]
[-- Type: text/x-patch, Size: 760 bytes --]

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 17f00b5a1de21de35366b82040a7ad46d65f899e..ee3ebe4561ea3d9791fabdfcec8b16af63bd4d20 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -10321,8 +10321,10 @@ arm_new_rtx_costs (rtx x, enum rtx_code code, enum rtx_code outer_code,
 	      /* SMUL[TB][TB].  */
 	      if (speed_p)
 		*cost += extra_cost->mult[0].extend;
-	      *cost += rtx_cost (XEXP (x, 0), mode, SIGN_EXTEND, 0, speed_p);
-	      *cost += rtx_cost (XEXP (x, 1), mode, SIGN_EXTEND, 1, speed_p);
+	      *cost += rtx_cost (XEXP (XEXP (x, 0), 0), mode,
+				 SIGN_EXTEND, 0, speed_p);
+	      *cost += rtx_cost (XEXP (XEXP (x, 1), 0), mode,
+				 SIGN_EXTEND, 1, speed_p);
 	      return true;
 	    }
 	  if (speed_p)

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH][ARM][2/4] Fix operand costing logic for SMUL[TB][TB]
  2016-01-22  9:52 [PATCH][ARM][2/4] Fix operand costing logic for SMUL[TB][TB] Kyrill Tkachov
@ 2016-02-04  9:00 ` Ramana Radhakrishnan
  2016-02-29 12:18   ` Kyrill Tkachov
  0 siblings, 1 reply; 4+ messages in thread
From: Ramana Radhakrishnan @ 2016-02-04  9:00 UTC (permalink / raw)
  To: Kyrill Tkachov
  Cc: GCC Patches, Ramana Radhakrishnan, Richard Earnshaw, Jim Wilson

On Fri, Jan 22, 2016 at 9:52 AM, Kyrill Tkachov
<kyrylo.tkachov@foss.arm.com> wrote:
> Hi all,
>
> As part of investigating the codegen effects of a fix for PR 65932 I found
> we assign
> too high a cost for the sign-extending multiply instruction SMULBB.
> This is because we add the cost of a multiply-extend but then also recurse
> into the
> SIGN_EXTEND sub-expressions rather than the registers (or subregs) being
> sign-extended.
>
> This patch is a simple fix. The fix is right by itself, but in combination
> with patch 3
> fix the gcc.target/arm/wmul-2.c testcase.
>
> Bootstrapped and tested on arm-none-linux-gnueabihf.
>
> Ok for trunk?
>

OK.

Thanks,
Ramana
> Thanks,
> Kyrill
>
> 2016-01-22  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>
>
>     * config/arm/arm.c (arm_new_rtx_costs, MULT case): Properly extract
>     the operands of the SIGN_EXTENDs from a SMUL[TB][TB] rtx.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH][ARM][2/4] Fix operand costing logic for SMUL[TB][TB]
  2016-02-04  9:00 ` Ramana Radhakrishnan
@ 2016-02-29 12:18   ` Kyrill Tkachov
  0 siblings, 0 replies; 4+ messages in thread
From: Kyrill Tkachov @ 2016-02-29 12:18 UTC (permalink / raw)
  To: Ramana Radhakrishnan, Christophe Lyon
  Cc: GCC Patches, Ramana Radhakrishnan, Richard Earnshaw, Jim Wilson


On 04/02/16 09:00, Ramana Radhakrishnan wrote:
> On Fri, Jan 22, 2016 at 9:52 AM, Kyrill Tkachov
> <kyrylo.tkachov@foss.arm.com> wrote:
>> Hi all,
>>
>> As part of investigating the codegen effects of a fix for PR 65932 I found
>> we assign
>> too high a cost for the sign-extending multiply instruction SMULBB.
>> This is because we add the cost of a multiply-extend but then also recurse
>> into the
>> SIGN_EXTEND sub-expressions rather than the registers (or subregs) being
>> sign-extended.
>>
>> This patch is a simple fix. The fix is right by itself, but in combination
>> with patch 3
>> fix the gcc.target/arm/wmul-2.c testcase.
>>
>> Bootstrapped and tested on arm-none-linux-gnueabihf.
>>
>> Ok for trunk?
>>
> OK.

Is it ok to backport this to the GCC 5 branch?
It fixes a testcase with cortex-a5 tuning and was tested by Christophe:
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01238.html

Thanks,
Kyrill

> Thanks,
> Ramana
>> Thanks,
>> Kyrill
>>
>> 2016-01-22  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>
>>
>>      * config/arm/arm.c (arm_new_rtx_costs, MULT case): Properly extract
>>      the operands of the SIGN_EXTENDs from a SMUL[TB][TB] rtx.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH][ARM][2/4] Fix operand costing logic for SMUL[TB][TB]
@ 2016-02-03  8:32 Nick Clifton
  0 siblings, 0 replies; 4+ messages in thread
From: Nick Clifton @ 2016-02-03  8:32 UTC (permalink / raw)
  To: kyrylo.tkachov; +Cc: gcc-patches

Hi Kyrill,

> 2016-01-22  Kyrylo Tkachov  <kyrylo.tkachov@arm.com>
> 
>     * config/arm/arm.c (arm_new_rtx_costs, MULT case): Properly extract
>     the operands of the SIGN_EXTENDs from a SMUL[TB][TB] rtx.

Approved - please apply.

Cheers
  Nick
  

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2016-02-29 12:18 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-22  9:52 [PATCH][ARM][2/4] Fix operand costing logic for SMUL[TB][TB] Kyrill Tkachov
2016-02-04  9:00 ` Ramana Radhakrishnan
2016-02-29 12:18   ` Kyrill Tkachov
2016-02-03  8:32 Nick Clifton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).