__mips16_xxx and .globl
I have implemented this gcc mips16 floating point scheme in llvm/clang and ran into one interesting issue. In gcc mips16, for all the hard float routines, i.e. __mips16_xxx, gcc emits a .globl for them. It does not do this for other routines like strcmp for example or puts. If don't remit the .globl's for these in -fPIC mode, then when I run this one heavy math use program, it runs really slow because it seems to be constantly in the loader doing something. If I edit the .s file and add the .globl's then it runs at normal speed. Does anyone know what the issue would be here? Without the .globl, the type is UNDEFINED and with the .globl the type of OBJECT for these __mips16_xxx routines. Reed
Re: __mips16_xxx and .globl
I forgot to mention that this only happens with Im linking as C++ On 08/29/2013 02:07 PM, Reed Kotler wrote: I have implemented this gcc mips16 floating point scheme in llvm/clang and ran into one interesting issue. In gcc mips16, for all the hard float routines, i.e. __mips16_xxx, gcc emits a .globl for them. It does not do this for other routines like strcmp for example or puts. If don't remit the .globl's for these in -fPIC mode, then when I run this one heavy math use program, it runs really slow because it seems to be constantly in the loader doing something. If I edit the .s file and add the .globl's then it runs at normal speed. Does anyone know what the issue would be here? Without the .globl, the type is UNDEFINED and with the .globl the type of OBJECT for these __mips16_xxx routines. Reed
issues related to implementation of mips16 naked attribute
I would like to move on to figuring out precisely what the issues are . What rules would make this attribute behave in a proper and understandable way? Maybe there are limitations that the user would have to be aware of. My main interest is in LLVM but there is great interest to keep the compiler semantics the same as gcc for most things. LLVM seems to have more or less decided that the naked attribute is useful and there is a desire to create a clear semantics of it across all targets. There is not any dissenting debate there on it's usefulness. BTW, the MicroChip Mips C compiler which is for embedded work does support the naked attribute. http://ww1.microchip.com/downloads/en/DeviceDoc/51686F.pdf One issue I can see is properly defining the state of the assembler that can be assumed up entry. For example, the state of .reorder, .noreorder. There are the .cfi issues which Richard S brought up. The issues of callee and caller saved registers which Richard S brought up. I would say that naked functions should preserve the ABI. If it can't then at the call site, the appropriate registers should be saved via inline asm. I would like to see the naked function appear to gcc as any external asm function would. That seems to get rid of most if not all problems. Reed
Re: naked function attribute support for Mips
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.
The main idea is that naked is there for someone that needs it.
The caller/callee saved register issue is there. In the absence of
additional function attributes, one would presume that normal abi rules
apply. But this issue is there even if you use assembly code instead of
functions with the naked attribute.
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 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
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
Re: naked function attribute support for Mips
Microchip which makes the Pic32 embedded processor (Mips32) has the naked attribute in their C compiler. http://ww1.microchip.com/downloads/en/DeviceDoc/51686F.pdf
naked function attribute support for Mips
This issue of naked function attribute support for Mips has come up in the context of LLVM and in regards to maintaining compatibility with gcc. It's my understanding that the idea of the naked function attribute was rejected for gcc Mips. I'm curious as to why. For LLVM it basically works just by nature of how LLVM works in its target independent part. It will not emit the function prologue or epilogue. It still emits the .frame, .mask and .fmask because that is Mips specific code that does not currently know about the naked function attribute, but that is a separate issue. There is also the issue of the return statement but this also a separate non Mips specific issue and I will post that separately. Tia. Reed
return statement in a function with the naked attribute
Should a return statement be emitted in a function that has the naked attribute. There seems to be some confusion here and apparently disagreement between various gcc compilers.
Re: return statement in a function with the naked attribute
On 05/02/2013 03:44 PM, reed kotler wrote: Should a return statement be emitted in a function that has the naked attribute. There seems to be some confusion here and apparently disagreement between various gcc compilers. Sorry. This was meant to be a question. Should a return statement be emitted in a function that has the naked attribute? Tia. Reed
Re: naked function attribute support for Mips
On 05/02/2013 04:13 PM, Andrew Pinski wrote: On Thu, May 2, 2013 at 3:35 PM, reed kotler rkot...@mips.com wrote: This issue of naked function attribute support for Mips has come up in the context of LLVM and in regards to maintaining compatibility with gcc. It's my understanding that the idea of the naked function attribute was rejected for gcc Mips. I'm curious as to why. For LLVM it basically works just by nature of how LLVM works in its target independent part. It will not emit the function prologue or epilogue. It still emits the .frame, .mask and .fmask because that is Mips specific code that does not currently know about the naked function attribute, but that is a separate issue. There is also the issue of the return statement but this also a separate non Mips specific issue and I will post that separately. What are the use cases of naked for mips that the interrupt attribute does not handle? Including the use_shadow_register_set, keep_interrupts_masked and use_debug_exception_return attributes which MIPS backend already handles. Thanks, Andrew Pinski For me, the reason would be so that you can control what is in the function more precisely. This would be for whatever reason you might not want default behavior from some other attribute.
Re: return statement in a function with the naked attribute
On 05/02/2013 04:16 PM, Andrew Pinski wrote: On Thu, May 2, 2013 at 3:46 PM, reed kotler rkot...@mips.com wrote: On 05/02/2013 03:44 PM, reed kotler wrote: Should a return statement be emitted in a function that has the naked attribute. There seems to be some confusion here and apparently disagreement between various gcc compilers. Sorry. This was meant to be a question. Should a return statement be emitted in a function that has the naked attribute? I don't see why there is any confusion about this for interrupt handlers on MIPS (the interrupt attribute being used here). They either use eret or deret which is controlled by the use of the use_debug_exception_return attribute. This is not a Mips specific question. It's a general question about the naked attribute for functions. Should a return statement be emitted in a function that has the naked attribute? Thanks, Andrew Pinski Tia. Reed
Re: return statement in a function with the naked attribute
On 05/02/2013 07:54 PM, Ian Lance Taylor wrote: On Thu, May 2, 2013 at 3:44 PM, reed kotler rkot...@mips.com wrote: Should a return statement be emitted in a function that has the naked attribute. I vote yes. why would you want that? naked functions are just inline asm. you can generate your own return statement. I meant to end that statement with a question mark. :) There seems to be some confusion here and apparently disagreement between various gcc compilers. Which targets do not generate a return instruction for a naked function? I don't think that any that support naked functions emit a return instruction. Ian
Re: return statement in a function with the naked attribute
On 05/02/2013 08:41 PM, Chung-Ju Wu wrote: 2013/5/3 reed kotler rkot...@mips.com: Should a return statement be emitted in a function that has the naked attribute. There seems to be some confusion here and apparently disagreement between various gcc compilers. IMHO, it depends on how you define the word 'naked' for a function and how you expect one writing functions with 'naked' attribute. If you think one is supposed to have *complete* control in the function (i.e. only inline assembly code, without using any C statement and variables), then the asm 'ret' can be omitted. Porgrammers must explicitly emit 'ret' in the inline asm. If you allow user using C statement in the function with 'naked' attribute, the asm 'ret' is still required. Because compiler may produce a branch to the epilogue position where 'ret' is expected to exist. AFAIK, there is no standard defining what 'naked' behavior should be. So gcc leaves it to back-end developers. Best regards, jasonwucj I think that the compiler should respect any return statements you explicitly enter, but should not create any that are implied as in reaching the end of the function.
Re: return statement in a function with the naked attribute
On 05/02/2013 09:06 PM, Ian Lance Taylor wrote: On Thu, May 2, 2013 at 8:59 PM, reed kotler rkot...@mips.com wrote: On 05/02/2013 07:54 PM, Ian Lance Taylor wrote: On Thu, May 2, 2013 at 3:44 PM, reed kotler rkot...@mips.com wrote: Should a return statement be emitted in a function that has the naked attribute. I vote yes. why would you want that? naked functions are just inline asm. you can generate your own return statement. I meant to end that statement with a question mark. :) There seems to be some confusion here and apparently disagreement between various gcc compilers. Which targets do not generate a return instruction for a naked function? I don't think that any that support naked functions emit a return instruction. Well, if they all agree, then clearly that is what we should do. But you said there was some confusion. To what were you referring? Ian There was some confusion on the llvm list because some tests were run on targets that did not support the naked attribute. I think we are thinking now that the return statement should not be emitted unless explicitly requested. It's not totally clear in the gcc manual so that is why I was asking.
mips16 stubs
Consider the following function:
void floatvf(float x) {
}
The compiled with:
mips-linux-gnu-gcc -mips16 mips16_fpcall.c -S -fPIC -EL
The stub looks like this:
__fn_stub_floatvf:
.setnoreorder
.cpload$25
.setreorder
.reloc0,R_MIPS_NONE,floatvf
la$25,__fn_local_floatvf
mfc1$4,$f12
jr$25
.end__fn_stub_floatvf
__fn_local_floatvf = floatvf
What is the purpose of this .reloc and this __fn_local_floatvf = floatvf ?
The stub is in it's own section.
TIA.
Reed
section attribute
I tried to report a bug against llvm for not properly handling the
section attribute but they claim that it's not the intention for gcc to
work this way.
I reported it as an X86 problem because it's more generally
understandable to people but actually the problem occurs when mips16
generates stubs for floating point interoperability with mips32.
The gcc documentation ways that the section attribute takes the section
name.
What is the real rule?
Is this feature used by other ports except for gcc mips16?
TIA.
Reed
Here is what I reported:
Consider the following code:
void x(int i) __attribute((section(.mySection,\aw\,@progbits#)));
void x(int i) {
}
If you compile this with gcc you get:
.filesectbug.c
.section.mySection,aw,@progbits#,ax,@progbits
.globl x
With Clang you get
.filesectbug.c
.section.mySection,\aw\,@progbits#,ax,@progbits
.globlx
Re: section attribute
My mistake here.
I have not used the section attribute myself much and was looking at gcc
code
just passed the right handside of the .section to the attribute string.
# Stub function for foovf (float)
.section.mips16.fn.foovf,ax,@progbits
.align2
.setnomips16
.setnomicromips
.ent__fn_stub_foovf
.type__fn_stub_foovf, @function
__fn_stub_foovf:
la$25,foovf
mfc1$4,$f12
jr$25
.end__fn_stub_foovf
.text
$__fn_local_foovf = foovf
--More--(55%)
On 04/19/2013 08:22 AM, reed kotler wrote:
I tried to report a bug against llvm for not properly handling the
section attribute but they claim that it's not the intention for gcc
to work this way.
I reported it as an X86 problem because it's more generally
understandable to people but actually the problem occurs when mips16
generates stubs for floating point interoperability with mips32.
The gcc documentation ways that the section attribute takes the
section name.
What is the real rule?
Is this feature used by other ports except for gcc mips16?
TIA.
Reed
Here is what I reported:
Consider the following code:
void x(int i) __attribute((section(.mySection,\aw\,@progbits#)));
void x(int i) {
}
If you compile this with gcc you get:
.filesectbug.c
.section.mySection,aw,@progbits#,ax,@progbits
.globl x
With Clang you get
.filesectbug.c
.section.mySection,\aw\,@progbits#,ax,@progbits
.globlx
CPIC for mips
CPIC is added to .o files for mips a lot. Is that needed? What is it for? Tia. Reed rkotler@ubuntu-rkotler:~/testmips16$ mips-linux-gnu-gcc null.c -c mipsrkotler@ubuntu-rkotler:~/testmips16$ mips-linux-gnu-objdump -x null.o null.o: file format elf32-tradbigmips null.o architecture: mips:isa32r2, flags 0x0011: HAS_RELOC, HAS_SYMS start address 0x private flags = 70001005: [abi=O32] [mips32r2] [not 32bitmode] [noreorder] [CPIC] Sections: Idx Name Size VMA LMA File off Algn 0 .text 0030 0040 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 0070 2**4 CONTENTS, ALLOC, LOAD, DATA 2 .bss 0070 2**4 ALLOC 3 .reginfo 0018 0070 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA, LINK_ONCE_SAME_SIZE 4 .pdr 0020 0088 2**2 CONTENTS, RELOC, READONLY 5 .mdebug.abi32 00a8 2**0 CONTENTS, READONLY 6 .comment 002c 00a8 2**0 CONTENTS, READONLY 7 .gnu.attributes 0010 00d4 2**0 CONTENTS, READONLY SYMBOL TABLE: ldf *ABS* null.c ld .text .text ld .data .data ld .bss .bss ld .mdebug.abi32 .mdebug.abi32 ld .reginfo .reginfo ld .pdr .pdr ld .comment .comment ld .gnu.attributes .gnu.attributes g F .text0024 main RELOCATION RECORDS FOR [.pdr]: OFFSET TYPE VALUE R_MIPS_32 main rkotler@ubuntu-rkotler:~/testmips16$
mips16 and nomips16
I'm not understanding why mips16 and nomips16 are not simple inheritable attributes. i..e you should be able to say: void foo(); void __attribute((nomips16)) foo(); or void goo(); void __attribute((mips16)) goo(); There does not seem to be any other cases in gcc where this would not be allowed. Tia. Reed
Re: mips16 and nomips16
On 01/14/2013 04:50 PM, David Daney wrote: On 01/14/2013 04:32 PM, reed kotler wrote: I'm not understanding why mips16 and nomips16 are not simple inheritable attributes. The mips16ness of a function must be known by the caller so that the appropriate version of the JAL/JALX instruction can be emitted i..e you should be able to say: void foo(); void __attribute((nomips16)) foo(); or void goo(); Any call here would assume nomips16 void __attribute((mips16)) goo(); A call here would assume mips16. Which is it? If you allow it to change, one case will always be incorrect. Or perhaps I misunderstand the question. David Daney I would assume that foo would be nomips16 and goo would be mips16. The definition of plain foo() or goo() says that nothing is specified. What is not clear then? This is how all such other attributes in gcc are handled.
inline assembly
For extended inline assembly, there are constraints. Some seem to be supported by all architectures and some specific to a particular architecture. Where are these defined in gcc source? Some seem to be in constraints.md and some not. Tia. Reed
