[PATCH][ARM][2/4] Fix operand costing logic for SMUL[TB][TB]

2016-01-22 Thread Kyrill Tkachov
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 regist

Re: [PATCH][ARM][2/4] Fix operand costing logic for SMUL[TB][TB]

2016-02-29 Thread Kyrill Tkachov
On 04/02/16 09:00, Ramana Radhakrishnan wrote: On Fri, Jan 22, 2016 at 9:52 AM, Kyrill Tkachov 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 cos

Re: [PATCH][ARM][2/4] Fix operand costing logic for SMUL[TB][TB]

2016-02-03 Thread Nick Clifton
Hi Kyrill, > 2016-01-22 Kyrylo Tkachov > > * 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

Re: [PATCH][ARM][2/4] Fix operand costing logic for SMUL[TB][TB]

2016-02-04 Thread Ramana Radhakrishnan
On Fri, Jan 22, 2016 at 9:52 AM, Kyrill Tkachov 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 rec