This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: naked function attribute support for Mips
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: reed kotler <rkotler at mips dot com>, Chung-Ju Wu <jasonwucj at gmail dot com>, gcc at gcc dot gnu dot org, rdsandiford at googlemail dot com
- Date: Fri, 3 May 2013 12:44:53 +0200
- Subject: Re: naked function attribute support for Mips
- References: <5182EA47 dot 2080804 at mips dot com> <CADj25HNcL_5DXjZbWUFgqEotc_cau--+kPi87cCpW3uTKh=f1A at mail dot gmail dot com> <CADj25HOgZi8DQGRsCHwmcXsZZ_rrSzgiT0azoRqB=h6YUBRpQQ at mail dot gmail dot com> <518374DA dot 6020803 at mips dot com> <87a9ocnyp1 dot fsf at sandifor-thinkpad dot stglab dot manchester dot uk dot ibm 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.