Re: Question on cse_not_expected in explow.c:memory_address_addr_space()

[Georg-Johann Lay <avr at gjlay dot de>]

Paolo Bonzini schrieb:
> On 09/28/2011 02:14 PM, Georg-Johann Lay wrote:
>> This leads to unpleasant code. The machine can access all RAM
>> locations by
>> direct addressing. However, the resulting code is:
>>
>> foo:
>>     ldi r24,lo8(-86)     ;  6    *movqi/2    [length = 1]
>>     ldi r30,lo8(-64)     ;  34    *movhi/5    [length = 2]
>>     ldi r31,lo8(10)
>>     std Z+3,r24     ;  7    *movqi/3    [length = 1]
>> .L2:
>>     lds r24,2754     ;  10    *movqi/4    [length = 2]
>>     sbrs r24,7     ;  43    *sbrx_branchhi    [length = 2]
>>     rjmp .L2
>>     ldi r24,lo8(-69)     ;  16    *movqi/2    [length = 1]
>>     ldi r30,lo8(-64)     ;  33    *movhi/5    [length = 2]
>>     ldi r31,lo8(10)
>>     std Z+3,r24     ;  17    *movqi/3    [length = 1]
>> .L3:
>>     lds r24,2754     ;  20    *movqi/4    [length = 2]
>>     sbrs r24,7     ;  42    *sbrx_branchhi    [length = 2]
>>     rjmp .L3
>>     ret     ;  39    return    [length = 1]
>>
>> Insn 34 loads 2752 (0xAC0) to r30/r31 (Z) and does an indirect access
>> (*(Z+3),
>> i.e. *2755) in insn 7.  The same happens in insn 33 (load 2752) and
>> access
>> (insn 17).
>>
>> Is there a way to avoid this? I tried -f[no-]rerun-cse-after-loop but
>> without
>> effect, same for -Os/-O2 and trying to patch rtx_costs.
>> cse_not_expected is
>> overridden in some places in the middle-end.
> 
> fwprop should take care of propagating the address.  Have you tried
> patching address_costs?  Might be as simple as this (untested):
> 
> Index: avr.c
> ===================================================================
> --- avr.c    (revision 177688)
> +++ avr.c    (working copy)
> @@ -5986,8 +5986,8 @@ avr_address_cost (rtx x, bool speed ATTR
>      return 18;
>    if (CONSTANT_ADDRESS_P (x))
>      {
> -      if (optimize > 0 && io_address_operand (x, QImode))
> -    return 2;
> +      if (optimize > 0)
> +    return io_address_operand (x, QImode) ? 2 : 3;
>        return 4;
>      }
>    return 4;
> 
> Paolo


At present, avr_address_cost returns a cost of 4 for all addresses:

avr_address_cost[foo:fwprop1(160)]: 4 = (plus:HI (reg/f:HI 46)
    (const_int 3 [0x3]))

avr_address_cost[foo:fwprop1(160)]: 4 = (const_int 2755 [0xac3])

avr_address_cost[foo:loop2_invariant(171)]: 4 = (const_int 2752 [0xac0])

These are all calls to avr_address_cost during compilation.

Odd, with a cost of 2 for CONST_INT addresses (same for cost = 1), the first
load (insn 7) is direct but the second (insns 32 and 17) is still there:

foo:
	ldi r24,lo8(-86)	 ;  6	*movqi/2	[length = 1]
	sts 2755,r24	 ;  7	*movqi/3	[length = 2]
.L2:
	lds r24,2754	 ;  10	*movqi/4	[length = 2]
	sbrs r24,7	 ;  41	*sbrx_branchhi	[length = 2]
	rjmp .L2
	ldi r24,lo8(-69)	 ;  16	*movqi/2	[length = 1]
	ldi r30,lo8(-64)	 ;  32	*movhi/5	[length = 2]
	ldi r31,lo8(10)
	std Z+3,r24	 ;  17	*movqi/3	[length = 1]
.L3:
	lds r24,2754	 ;  20	*movqi/4	[length = 2]
	sbrs r24,7	 ;  40	*sbrx_branchhi	[length = 2]
	rjmp .L3
	ret	 ;  37	return	[length = 1]

Again, raising CONST_INT costs in avr_rtx_costs does not help.

The costs of *(Z+3) are actually smaller than *(2755), they are 2 compared to
4.  If *all* accesses to a constant address would have been CSEd out the
program would not be bad, but a mixture of both methods is not good.

It's not possible to make a best choice without a reasonable guess for register
pressure of address registers.

Thus, for CONST_INT addresses it might be profitable to return cost that is
smaller than the real cost because accesses to CONST_INT addresses are very
likely to be accesses to I/O. (Not all I/O is element of io_address_operand,
some part of I/O has to be accomplished by "ordinary" RAM access like here).

And CSEing too much addresses might increase the register pressure for the two
pointer registers of AVR (and just one besides frame pointer) too much, so that
CONST_INT addresses should be accessed directly and not indirect.

Johann