[PATCH] hppa: Improve expansion of ashldi3 when !TARGET_64BIT

Roger Sayle roger@nextmovesoftware.com
Thu Aug 27 07:16:50 GMT 2020


>On 2020-08-26 5:23 p.m., Roger Sayle wrote:
>> These more accurate target rtx_costs are used by the 
>> gimple-ssa-strength-reduction.c (via a call to mult_by_coeff_cost) to 
>> decide whether applying strength reduction would be profitable.  This test case, slsr-13.c, assumes that two multiplications by four are
>> cheaper than two multiplications by five.   (I believe) This is not the case on hppa which
>> has a sh2add instruction, that performs a multiplication by five in 
>> one cycle, or exactly the same cost as performing a left shift by two 
>> (i.e. a multiplication by four).  Oddly, I also believe this isn't the 
>> case on x86_64, where the similar lea instruction is (sometimes) as efficient as left shift by two bits.
>This looks like a regression.
>
>gcc-10 (prepatch):
>
>        addl %r25,%r26,%r28
>        sh2addl %r25,%r28,%r25
>        sh2addl %r26,%r28,%r26
>        addl %r26,%r28,%r28
>        bv %r0(%r2)
>        addl %r28,%r25,%r28
>
>  <bb 2> [local count: 1073741824]:
>  x1_4 = c_2(D) + s_3(D);
>  slsr_11 = s_3(D) * 4;
>  x2_6 = x1_4 + slsr_11;
>  slsr_12 = c_2(D) * 4;
>  x3_8 = x1_4 + slsr_12;
>  _1 = x1_4 + x2_6;
>  x_9 = _1 + x3_8;
>  return x_9;
>
>gcc-11 (with patch):
>
>        addl %r25,%r26,%r19
>        sh2addl %r26,%r26,%r28
>        addl %r28,%r25,%r28
>        sh2addl %r25,%r25,%r25
>        addl %r28,%r19,%r28
>        addl %r25,%r26,%r26
>        bv %r0(%r2)
>        addl %r28,%r26,%r28
>
>  <bb 2> [local count: 1073741824]:
>  x1_4 = c_2(D) + s_3(D);
>  a2_5 = s_3(D) * 5;
>  x2_6 = c_2(D) + a2_5;
>  a3_7 = c_2(D) * 5;
>  x3_8 = s_3(D) + a3_7;
>  _1 = x1_4 + x2_6;
>  x_9 = _1 + x3_8;
>  return x_9;
>
> Regards,
> Dave

There are two interesting (tree-optimization) observations here.  The first is that at the tree-ssa
level both of these gimple sequences look to have exactly the same cost, seven assignments on
a target where *4 is the same cost as *5.  The gimple doesn't attempt to model the sh?add/lea
instructions that combine may find, so at RTL expansion both sequences look equivalent.  One
fix may be to have gimple-ssa-strength-reduction.c just prefer multiplications by 2, 4 and 8,
even on targets that have a single cycle "mul" instruction.

The second observation is why isn't tree-ssa-reassoc.c doing something here.  The test case
is evaluating (s+c)+(s+5*c)+(5*s+c), and this strength reduction test is expecting this to turn
into "tmp=s+c;  return tmp+(tmp+4*c)+(4*s+tmp" which is clever and an improvement, but
overlooks the obvious reassociation 7*(s+c).  Indeed LLVM does this in three instructions:

	tmp1 = s+c;
	tmp2 = tmp1<<3;
	return tmp2-tmp1;

Although the PA backend is (mostly) innocent in this, the lowest impact fix/work around is
to have multiplications by 2, 4 and 8 return COSTS_N_INSNS(1)-1, to indicate a preference
when splitting ties.  I'll prepare a patch.

Roger
--




More information about the Gcc-patches mailing list