avr-gcc-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re "nake


From: Georg-Johann Lay
Subject: Re: [avr-gcc-list] Weird optimization issue with avr-gcc 4.5.3, re "naked."
Date: Fri, 27 Jan 2012 18:36:50 +0100
User-agent: Thunderbird 2.0.0.24 (X11/20100302)

William "Chops" Westfield wrote:

Hi, don't forget to use "reply to all" or at least to CC the lists themselves.

> On Jan 27, 2012, at 3:23 AM, Georg-Johann Lay wrote:
> 
>>> 4.5.3 ?  Whatever this issue is, it apparently snuck in between 4.5.2
>>> and 4.5.3.
>> The only remarkable difference between 4.5.2 and 4.5.3 is the fix of
>> PR42240.
> 
> That looks exactly relevant.
> 
> "The patch implements target hook TARGET_CANNOT_MODIFY_JUMPS_P in order to
> inhibit post-reload bb reorder for naked functions."
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42240
> 
> It looks like the patch to prevent reordering of instructions past the
> epilogue of naked functions prevents such reordering for the entire naked
> function.

Yes.

> Though I'm not sure I understand why the original complaint was considered a
> bug. They appear to have been counting on a naked C function to fall in at
> the top and fall out at the bottom, which seems like even more of an abuse
> of "naked" than I was using (though I guess allowing that behavior is
> useful, especially in init code.)
> 
> Thanks!
> 
> BillW

Yes. The reason why naked is there is that code can be put into .initN section.
The code there is just like you lined out: enter at "top" an exit at "bottom"
because such functions are not called, they are just collected and put in the
respective .init section, one after one, like a pile of code.

Naked will work with assembler code, but people also write C code to live in
.init (making assumptions like there won't be a frame needed etc.).

This means that you run into considerable problems if an epilogue (there may be
more than one) is in the middle of the function.

PR42240 fixes this and tries to make as much code as possible work together
with naked at the expense of some additional instructions.

OS_main/OS_task won't have the problem, but such functions cannot be used in
.initN, of course. Except in the case where the code is in .init9 with custom
startup code.

Johann



reply via email to

[Prev in Thread] Current Thread [Next in Thread]