[LLVMdev] funny llvm bug
rkotler at mips.com
Fri Apr 19 09:47:28 PDT 2013
This came about in trying to implement some stubs used by gcc mips16 for
allowing floating point interoperability with mips32.
You get the following looking code from gcc -mips16:
# Stub function for foovf (float)
.section .mips16.fn.foovf,"ax", at progbits
.type __fn_stub_foovf, @function
$__fn_local_foovf = foovf
Not being sure about the restriction of section to just "name", well
docs can be wrong and not match the code, I Googled for this:
This implied that it was okay to do what I tried.
I have not looked at how gcc implements this internally but in LLVM I'm
creating real IR for a function (the stub being in mips32 mode; even
though the rest of the compilation unit is being compiled in mips16
mode). This is one (not the only) reason why I implemented the ability
to switch processor modes on a per function basis.
As Joerg pointed out, I could create the section change myself with
inline assembly.I'm not really comfortable emitting inline assembly from
the compiler that has anything other than instructions or something in
direct support of an instruction stream and not things that could
interfere with the global sequencing of things like sections by the
compiler. While users can do this; they are then more responsible for
making sure that they have not shot themselves in the foot. On the other
side, since these are "naked" functions, one could argue that changing
sections is safe to do inside the function itself.
We do have some ability in MIPS16 to do inline assembly in the presence
of the direct object emitter but I'm not sure if it could do something
like this right now.
The clean solution is probably to add two additional function attributes
to cover these additional pieces, namely "ax" and @progbits.
On 04/19/2013 03:40 AM, Rafael Espíndola wrote:
>> It is exactly intended to handle section names as what they are --
>> section names. The only reason it works with GCC is because it writes an
>> assembler stream.
> Reed, this fails in gcc if you do LTO, no?
More information about the llvm-dev