llvm dev - Apr 2013 - [LLVMdev] funny llvm bug

> 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.
+1

Reed, this fails in gcc if you do LTO, no?
> Joerg
Cheers,
Rafael

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
	.align	2
	.set	nomips16
	.set	nomicromips
	.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


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:

http://stackoverflow.com/questions/6252812/what-does-the-aw-flag-in-the-section-attribute-mean

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.

Thoughts?

Reed


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.
>
> +1
>
> Reed, this fails in gcc if you do LTO, no?
>
>> Joerg
>
> Cheers,
> Rafael
>

On Fri, Apr 19, 2013 at 09:47:28AM -0700, reed kotler
wrote:
> The clean solution is probably to add two additional function
> attributes to cover these additional pieces, namely "ax" and
> @progbits.
Extend the section attribute to allow additional parameters?

Joerg

> 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.
Now that I see where this is from, why don't you add an attribute
(calling convention?) to the function saying it is a thunk and then
the mips backend can print the correct assembly to put it in a
separate section with the correct flags.

This looks somewhat similar to some functions being printed to
different comdat sections. Follow the compilation of

define weak_odr void @bar() {
  ret void
}

noticed how the IL has no explicit section, but the assembly has

.section .text.bar,"axG", at progbits,bar,comdat


Cheers,
Rafael