[cfe-dev] naked attribute

[reed kotler]

On 05/06/2013 08:08 AM, Rafael Espíndola wrote:
> On 3 May 2013 15:55, Reed Kotler <rkotler at mips.com> wrote:
>> My original main post was on the idea of not emitting implicit "return"
>> statements, and instead to emit implicit "unreachable".
>>
>> However if the code contains an explicit "return", clang should honor that.
> I tested
>
> __attribute__((naked)) void f1(void) {
> }
> __attribute__((naked)) void f2(void) {
>    return;
> }
> __attribute__((naked)) int f3(void) {
> }
> __attribute__((naked)) int f4(void) {
>    return 42;
> }
> void g(void);
> __attribute__((naked)) void f5(int a) {
>    if (a)
>      return;
>     g();
> }
>
>
> on ARM and gcc only produces return instructions when there is a value
> involved (f4). Given that this is fairly insane and documented to not
> be safe, I think your proposal is OK. Always producing an unreachable
> would also be I think.
>
> Anton, the lack of documentation makes the stronger point for warning,
> no? Reed, -allow-naked would be redundant with a -Werror if we do
> implement the warning, no?
>
> Cheers,
> Rafael
-allow-naked would allow the attribute to be honored even if gcc does 
not permit it for that target.
That would be different than just suppressing the warning. So the target 
could in effect support implemented and not implemented; in order to 
maintain gcc compatibility. For example, gcc does not current support 
the naked attribute for mips but I would like to see us have the option 
for llvm and we already have added that code.

If you use Antons approach, it would not be an option for the backends 
for particular targets to ignore the naked attribute.

They would get the unreachable instructions and the emit 
prologue/epilogue would not be called. This has the advantage of 
enforcing a unifying semantics for this across llvm, with the negative 
of not doing the same thing gcc would do, which is to allow the backend 
ports to ignore the naked attribute.

Reed