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

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

Re: [avr-gcc-list] Link Time Optimization vs __builtin_unreachable() and


From: Georg-Johann Lay
Subject: Re: [avr-gcc-list] Link Time Optimization vs __builtin_unreachable() and .signature?
Date: Mon, 18 Jun 2012 19:31:00 +0200
User-agent: Thunderbird 2.0.0.24 (X11/20100302)

Bob Paddock wrote:
> With the release of GCC 4.7.1 I wanted to give Link Time Optimization
> a try.  I'm using this version:
> http://sourceforge.net/projects/mobilechessboar/files/avr-gcc%20snapshots%20(Win32)
> 
> Part is Xmega128A1.
> 
> Adding -flto and -flto-report:
> 
> CFLAGS += -flto
> CFLAGS += -flto-report
> 
> LDFLAGS += -flto
> LDFLAGS += -flto-report
> 
> Reduced the project code size by a mind boggling ~52K.  Would be nice,
> alas it is not, traced the problem to this:
> 
> void reset_hardware( void )  __attribute__ ((__noreturn__)); /* Force
> a system reset.  We only return from this function by a hardware reset
> */
> 
> /* Force a Hardware Reset: */
> void reset_hardware( void )
> {
>   CCPWrite( &RST.CTRL, RST_SWRST_bm );
>   __builtin_unreachable();
> }
> 
> With LTO all the code after __builtin_unreachable(); is gone, breaking
> the project.

Code after __builtin_unreachable() is unreachable, this not needed.

If you

int m;
void foo (void)
{
    m = 0;
    reset_hardware ();
    more_actions();
}

then more_actions is obviously unreachable and can be thrown away.
The the code before __builtin_unreachable has no side effects or side
effects for which the compiler can deduce that they are unused, then
that code can be optimized out, too. See "m = 0" in the sample.


> Replacing  __builtin_unreachable():
> 
> void reset_hardware( void )
> {
>   CCPWrite( &RST.CTRL, RST_SWRST_bm );
> 
>   for(;;)
>     ;
> }
> 
> then LTO reduces the code by a more realistic 775 bytes.
> 
> A question I have is why do I have to add either
> __builtin_unreachable(); or the empty for(;;) to suppress the
> 'noreturn function does return' warning message, when the function is declare
> __noreturn__?  Seems GCC and I don't agree on the usage of 'noreturn'
> as marking the function that it will indeed never return.

noreturn means that the the function never returns, i.e. code after a call
of such a function will never be executed. The noreturn attribute allows
additional optimizations.

If you claim a function is noreturn but there is a code path that can reach
the end of such a function, your claim is obviously wrong, thus the warning.

Note that the compiler has no knowledge on the magic of RST.CTRL.
I don't know how the macro exactly expands, presumably it's just some
inline assembler and SFR writes. This means that code execution resumes
after the sequence, except you tell so. This is accomplished by
__builtin_unreachable. It means "I never come here, any code after here
is dead".


> Also LTO is incompatible with:
> 
> #include <avr/signature.h> /* Place the chip's signature into the .elf
> output file.  Simply including this file does the work.  Must only
> appear in the project *once* */
> 
> %.elf: $(OBJ)
>       $(OBJDUMP) -s -j .signature $(OBJDIR)/$@
> 
> LTO has removed .signature, resulting in avr-objdump giving an error
> about .signature not being found.

I don't know about the guts of .signature.

Maybe it has the wrong section flags or needs a KEEP in the linker
script. If it's not referenced from C code (is it?) then it can
be thrown away. If there is an object in .signature that is
needed but never used, use __attribute__((__used__)) to indicate
it is used despite not referenced.

> Is there a way to mark .signature as precious at the source level?
> Adding -flto to all source files but one complicates the Makefile.

Johann




reply via email to

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