On Fri, May 3, 2013 at 12:29 PM, Richard Sandiford
<rdsandif...@googlemail.com> wrote:
> Glad to see the push-back on this :-)
>
> reed kotler <rkot...@mips.com> writes:
>> On 05/03/2013 01:06 AM, Chung-Ju Wu wrote:
>>> 2013/5/3 Chung-Ju Wu <jasonw...@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-patc...@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.
