Re: noreturn function attribute and ret asm instruction

["Zack Weinberg" <zack at codesourcery dot com>]

Jim Wilson <wilson@tuliptree.org> writes:

> On Fri, 2003-08-29 at 17:09, Kristis Makris wrote:
>> Would it be acceptable if an extra function attribute was added that
>> allowed generation of code without assuming that it is a function (hence
>> no "ret" at the end) ?
>
> I don't see any point to this.  The compiler optimizes away the ret if
> control flow does not reach the end of the function.  There is no need
> for a function attribute for this.
>
> The real problem here is that we have no support for asms that change
> flow of control.  Adding a function attribute to suppress the ret does
> not fix this.  Letting asms change flow of control would require syntax
> and semantic changes.  This would be a major change, and it isn't clear
> if it is a good idea.  It might impede optimization so much that it
> hurts more than it helps.

I think that the very limited concept of 'this asm() constitutes a
control barrier' could be safely and usefully added.  The canonical
example is the BUG() macro from Linux: a typical definition is

#define BUG()                           \
 __asm__ __volatile__(  "ud2\n"         \
                        "\t.word %c0\n" \
                        "\t.long %c1\n" \
                         : : "i" (__LINE__), "i" (__FILE__))

(ud2 is the i386 opcode guaranteed to raise an illegal instruction
exception.)  When used e.g. as

void foo(void) { BUG(); }

the assembly you get is

foo:
#APP
        ud2
        .word 7
        .long .LC0

#NO_APP
        ret

The 'ret' is unnecessary, control transfers from the ud2 to the
illegal instruction trap handler and never comes back.  But the
compiler doesn't know that.  The optimization benefits are more
significant in the usual case where BUG() is conditional.

My old suggestion was to express this by clobbering "pc", which
currently has no meaning.  This would require no syntax change.
The objection I remember is "use __builtin_trap()", but that is
not flexible enough to replace the above, nor is it universally
implemented.

zw