This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Path,AVR]: Improve loading of 32-bit constants
Denis Chertykov wrote:
> 2011/7/6 Georg-Johann Lay <avr@gjlay.de>:
>> Denis Chertykov wrote:
>>> 2011/7/6 Georg-Johann Lay <avr@gjlay.de>:
>>>> For loading a 32-bit constant in a register, there is room for
>>>> improvement:
>>>>
>>>> * SF can be handled the same way as SI and therefore the patch
>>>> adds a peep2 to produce a *reload_insf analogon to *reload_insi.
>>>>
>>>> * If the destination register overlaps NO_LD_REGS, values already
>>>> loaded into some other byte can be reused by a simple MOV.
>>>> This is helpful then moving values like, e.g. -2, -100 etc. because
>>>> all high bytes are 0xff.
>>>>
>>>> * 0.0f can be directly moved to memory.
>>>>
>>>> * The mov insns contain "!d" constraint. I see no reason to make "d"
>>>> expensive and discourage use of d-regs. A "*d" to hide is better
>>>> because it does it neither puts additional pressure on "d" nor
>>>> discourages "d".
>>>>
>>> I would like to have a real code examples.
>>>
>>> Denis.
>> Hi Denis.
>>
>> Attached you find a small C file and the asm that is generated by new
>> and old versions (-Os -mmcu=atmega88 -S -dp).
>>
>> I took away some regs as potential clobbers (or -fno-peephole2) to
>> show the effect of high register pressure. Bit even if a clobber was
>> available you can see that the new version is smarter in reusing
>> values, e.g. note the loading of -1L to r22-r25.
>
> I have asked about example of *d instead of !d.
> Just svn GCC with *d vs svn GCC !d.
>
>
> Denis.
Ah, I couldn't depict that from your question.
I thought it could help in cases like these:
long z;
void inc (long y)
{
z += y;
}
that gets compiled with -Os to
inc:
push r16
push r17
/* prologue: function */
/* frame size = 0 */
/* stack size = 2 */
.L__stack_usage = 2
lds r16,z
lds r17,z+1
lds r18,z+2
lds r19,z+3
add r16,r22
adc r17,r23
adc r18,r24
adc r19,r25
sts z,r16
sts z+1,r17
sts z+2,r18
sts z+3,r19
/* epilogue start */
pop r17
pop r16
ret
But with the *d the code is still the same and R16 chosen instead of
better R18. Maybe that's an IRA issue.
Looking again at the "*d" resp. "!d", I think the alternative is
superfluous because there is a "r" alternative and "d" is a subset of
"r", so allocator can always switch to "r" if it does not like or see "d".
I think we con remove that alternative, it's just confusing.
Johann