Re: naked function attribute support for Mips

[Richard Biener <richard dot guenther at gmail dot com>]

On Fri, May 3, 2013 at 12:29 PM, Richard Sandiford
<rdsandiford@googlemail.com> wrote:
> Glad to see the push-back on this :-)
>
> reed kotler <rkotler@mips.com> writes:
>> On 05/03/2013 01:06 AM, Chung-Ju Wu wrote:
>>> 2013/5/3 Chung-Ju Wu <jasonwucj@gmail.com>:
>>>> Or do you think 'naked' is still useful for some other cases in mips porting?
>>>> You can implement it and submit the patch to gcc-patches@gcc.gnu.org
>>>> and I believe the mips maintainers are willing to have review with you. :)
>>>>
>>> Oops~ I just noticed that the mips maintainer Richard Sandiford
>>> already had some thought about 'naked' attribute.
>>>
>>> Refer to:
>>> http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00660.html
>>>
>>>
>>> Best regards,
>>> jasonwucj
>> I think are many valid uses for the naked attribute.
>>
>> Here is a simple example:
>>
>> void foo() __attribute__((naked));
>>
>> void foo() {
>> #ifdef DEBUG
>>             C code
>> #else
>>             Production code in assembly
>> #endif
>> }
>>
>>
>> You may have a very different implementation of several or many
>> functions when the production mode is present but for purely debugging
>> logic, some C code could be there.
>
> I'm not convinced -- does anyone actually do this?  If so, do they do it
> for performance reasons?  It would be bad if the compiler's output was
> so poor that this was necessary.  Plus it prevents any kind of LTO,
> which seems strange for a routine that is presumably performance-critical.
> E.g. it stops the compiler from generating specialised clones, or from
> inlining part of the function and leaving the rest out-of-line.
>
> This is pedantic, but: in your example, the attribute should only be
> used in the "production code" case.  So in practice the whole function
> definition would be guarded by the #ifdef, with the attribute in the
> production arm but not in the debug arm.  In which case why not use
> a .S file?  It's surely nicer than having to write a (presumably
> relatively large) asm function as a C string.
>
> You say that naked attributes "just work".  But the problem is that
> corner cases keep cropping up.  Your return question is a good example.
> My understanding is that the compiler should never generate any code
> itself for a naked function, and that naked functions must be an asm and
> nothing else.  In particular, naked functions must not have a return statement.
>
> It's tempting to see:
>
>   int __attribute__((naked))
>   foo (void)
>   {
>     asm ("....");
>   }
>
> as a normal function in which the compiler just happens not generate
> any prologue and epilogue code.  But its reach is far wider than that.
> See e.g.:
>
>   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53633
>
> where the compiler must assume that the asm returns, which is something
> normal asms are not allowed to do.  Another difference is that normal
> asms must list the registers that they clobber (except for the usual
> MIPS rule that asms can clobber $1).  E.g. for:
>
>   int
>   foo (int x)
>   {
>     asm ("# foo");
>     return x;
>   }
>
> the compiler is free to assume that the asm clobbers neither $2 nor $4,
> and so we get:
>
> foo:
>         move    $2,$4
>         # foo
>         j       $31
>
> But the asm in a naked function is different, because we have to assume
> that the asm can change any call-clobbered register.  This matters if
> you're doing IPA to figure out which functions happen to preserve which
> "call-clobbered" registers (so that callers can treat them as call-saved
> instead).  Naked functions would be a special case that's easily forgotten.
>
> Then there are questions like: what .cfi_* directives, if any, should
> the compiler generate for a naked function?  Should it generate the
> .cfi_startproc and .cfi_endproc, or is that the asm's job?  The answer
> isn't really obvious.
>
> That's just a list from the top of my head, I doubt it's exhaustive. :-)

I agree with all of this.  For LTO we need a way to annotate toplevel
asm()s with the symbols they require and provide, so a naked function
foo would just become

int foo (int);
asm("....." : : : : <magic-provides-symbol foo>);

which is much cleaner - it is then really embedding a .S file into
the TU (for whatever reason, one being the ability to make foo .local).

Richard.