Hi Tamar,

On 07/06/17 16:09, Tamar Christina wrote:
Hi Kyrill,

I have updated the patch and regtested on arm-none-linux-gnueabihf.

OK for trunk?

Ok.
Thanks,
Kyrill

Thanks,
Tamar
________________________________________
From: Tamar Christina
Sent: Wednesday, June 7, 2017 11:15:49 AM
To: Kyrill Tkachov; GCC Patches
Cc: nd; Ramana Radhakrishnan; Richard Earnshaw; ni...@redhat.com
Subject: RE: [PATCH][GCC][ARM] Adjust costs so udiv is preferred over sdiv when 
both are valid. [Patch (2/2)]

Hi Kyrill,

diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c index
b24143e32e2f100000f3b150f7ed0df4fabb3cc8..ecc7688b1db6309a4dd694a8e
254e64abe14d7e3 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -9258,6 +9258,8 @@ arm_rtx_costs_internal (rtx x, enum rtx_code
code, enum rtx_code outer_code,
       *cost += COSTS_N_INSNS (speed_p ? extra_cost->mult[0].idiv : 0);
         else
       *cost = LIBCALL_COST (2);
+
+      *cost += (code == DIV ? 1 : 0);
         return false; /* All arguments must be in registers.  */


We usually try to avoid adjusting the costs in units other than
COSTS_N_INSNS.
Would adding COSTS_N_INSNS (1) here work?
If so, could you also add a comment here to describe why we're adjusting the
cost.
It would, I'm just slightly worried it might end up generating different code 
for DIV then.
The reason I have used a unit smaller than COSTS_N_INSNS it so that it should 
have any real
Impact on any other optimization as the cost is likely treated as an integer? 
It's only for things that
Compare the costs values between signed and unsigned would the small unit make 
a difference.

Since I think the compiler still has some hard coded cost limits somewhere it 
may be an issue, but I'm not
100% certain. I can make the change though.

       case MOD:
@@ -9280,7 +9282,7 @@ arm_rtx_costs_internal (rtx x, enum rtx_code
code, enum rtx_code outer_code,

       /* Fall-through.  */
       case UMOD:
-      *cost = LIBCALL_COST (2);
+      *cost = LIBCALL_COST (2) + (code == MOD ? 1 : 0);

Same here.

Thanks,
Kyrill


Reply via email to