Re: noreturn function attribute and ret asm instruction

[Kristis Makris <kristis dot makris at asu dot edu>]

I just formally requested this feature in bugzilla:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12284

> OK.  I see what you are trying to do.  This is outside the scope of the
> ISO C language standard, and all ABI standards I know of.  However, it
> does sound like a reasonable thing for the linux developers to ask from
> gcc.

Its just me working on this framework right now...but I see value in
such a gcc feature.

> There will need to be some definition work here.  Do you really need all
> registers preserved?  The ABI only requires that call-saved registers

Absolutely not. In my naive terminology, I need a "preserve_as_needed"
function attribute to tell gcc to preserve only the registers it will
decide to use as temporary placeholders (which only gcc will know which
those are). I can see use for a "preserve_all" attribute as well though.

If you read the bug entry in Bugzilla, Andrew Pinska recommended use of
the -fcall-used-<register> flag. It didn't appear to me as the same
feature I'm asking. After reading this:

http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Code-Gen-Options.html#Code%20Gen%20Options

it appeared to be the opposite actually. Maybe he meant
-fcall-save-register, but still I don't know which register gcc will use
internally.

> and function arguments be preserved.  (And for gcc, global register
> variables are preserved.)  It should be safe to clobber any
> call-clobbered register, unless perhaps linux is passing info via them
> that is hidden to the compiler.  Letting gcc clobber call-clobbered
> registers means a bit better performance in the handler.  Preserving
> call-clobbered registers means you get the same ABI as an interrupt
> handler, which means we can perhaps share some code.  Instead of having
> an rte at the end of the function, we would have essentially a sibling
> (tail) call.
> 
> There will be implementation work needed for all targets that are
> supported by linux.  I am not volunteering for this work.  This is
> probably the killer part, because you would have to find a volunteer to
> do all of this work.  You would need someone familiar with each target,
> or willing to learn each target, which makes this quite a bit of work.

I'm willing to have a look if pointed to where in the sources target
specific work should be done.

> The Objective C language needs a somewhat similar feature.  It is
> implemented via builtin_save_args and builtin_apply_all.  These are
> inefficient features that save and restore lots of register arguments
> and stack arguments.  Perhaps this same feature could be used to improve
> Objective C support.  I am not familiar enough with Objective C to know
> for sure whether this makes any sense though.

I'm clueless when it comes to gcc internal but wouldn't mind having a
look. Thanks for the insight Jim.