This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: naked function attribute support for Mips


On 05/03/2013 03:29 AM, Richard Sandiford 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

In llvm they have a high level ir instruction called "unreachable".

I can't see why the optimizer cannot just ignore the function.

Why is this naked C assembly function any more relevant to gcc than the external assembly file that you are proposing we use instead.

What would be good is to add another set of attributes to define the calling convention and caller/callee saved registers. I want to do this for llvm. That makes things even better.


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. :-)

Richard




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]