Georg-Johann Lay schrieb:
> In current trunk (r170704), 4.4-branch and 4.5-branch I observe the
> following optimization issue in IRA: It saves regs in the frame
> instead of in callee-saved registers which would be much smarter.
>
> In the following C source, foo2 is compiled as desired (push/pop r17
> to save r24). In foo1 and foo3 r24 is saved in the frame. The old
> lreg/greg allocator of 4.3-branch generates fine code for all functions.
>
> Saving a reg in the frame should only be done if running out of hard
> registers because setting up frame(pointer) and accessing frame is
> very expensive on avr.
>
> Maybe someone can give me a hint what's going wrong.
>
> gcc configured
>
> /gnu/source/gcc.gnu.org/trunk/configure --target=avr --prefix=...
> --enable-languages=c,c++ --disable-libssp --disable-libada
> --disable-nls --disable-shared
>
> and sources compiled
>
> with -Os -mmcu=atmega8 -c -dp -da -fira-verbose=100
>
> /*****************************************************/
> void bar0 (void);
> void bar1 (char);
>
> void foo1 (char x)
> {
> bar0();
> bar1(x);
> }
>
>
> char foo2 (char x)
> {
> bar1(x);
>
> return x;
> }
>
> char foo3 (char x)
> {
> bar0();
>
> return x;
> }
> /*****************************************************/
>
> FYI, I attached IRA dumps and asm output
>
> As far I can see target avr gives appropriate costs for memory and
> register moves.
>
> IRA printout is as follows:
>
Returning memory move costs 4 times higher (8 instead of 2) for QI
memory moves, IRA/reload generates code as expected.
Is there any other way than lying about the costs?
IRA doues not take into account costs implied by generating new stack
slots and setting up frame pointer. AFAIK there is no hook to
influence that. How can a target describe costs generated by setting
up stack slots and accessing them?
Johann
