[LLVMdev] issues with InlineAsm class and #APP/#NOAPP

[Reed Kotler]

I'm happy to send you my patch as it stands today.

It's not cleaned up yet all or tested thoroughtly but you can look at 
what I'm doing and maybe suggest some alternate paths and if it's not a 
matter of redoing everything, I would consider making some changes.

Here is a sample stub:

Consider this line of code:

extern float fpff(float);

We have no idea if this is a mips16 or mips32 function.

As I scan the IR, if I'm in a Mips16 function and see a call to this 
function, then I need to generate stub.

The mips16 function code which contains say :
x = fpff(y)

Is compiled in a form of soft float and it is not going to change at all 
in order to make it interoperate with mips32.

At link time, if the linker sees a stub as shown below, it will change 
to the call to fpff in the mips16 code to be a call to the stub.

The stub has two tasks:
1) first copy any integer argument registers that would have been using 
floating registers (if soft float for the mips16 code was not in 
effect). In this case the integer argument register R4, needs to be 
copied to floating point register f12.
2) make the actual call to fpff
3) When fpff returns, it must move any floating point registers that are 
used to return values, to where soft float would have mapped them to. In 
this case, it means that F0 must be copied to integer return register R2.

So this helper stub will work whether in reality fpff is compiled as 
mips16 or mips32.

There are similar issues for mip32 code calling mips16 code.
Return types that can be passed in registers include float, double, 
_Complex float and _Complex double.

Parameter signatures of the form below need to be remapped:

float
double
float, double
float, float
double, double
double, float

	.section	.mips16.call.fp.fpff,"ax", at progbits
	.align	2
	.set	nomips16
	.set	nomicromips
	.ent	__call_stub_fp_fpff
	.type	__call_stub_fp_fpff, @function
__call_stub_fp_fpff:
	mtc1	$4,$f12
	move	$18,$31
	jal	fpff
	mfc1	$2,$f0
	jr	$18
	.size	__call_stub_fp_fpff, .-__call_stub_fp_fpff
	.end	__call_stub_fp_fpff



On 04/24/2013 04:25 PM, Rafael Espíndola wrote:
>> We also wanted the stubs to be real functions to llvm. That allows them to
>> participate properly
>> in optimization of various levels (including LTO). They can even be inlined.
>> There are other
>> planned optimizations that would not work if they were not legitimate
>> functions.
>
> I am not saying that the functions should not exist in the IL, just
> that they should not be inline assembly.
>
>> Arm does not have this ability to compile both thumb1 and ARM
>> functions in the same source file in LLVM so they would not have had the
>> option to do this in the IR.
>
> But llvm has to represent it when one IL file with thumb and one with
> ARM code are linked. I think this was one of the motivations for the
> current work on extending attributes.
>
>> I'm almost done now and not going to revisit the whole design at this point.
>
> Which is a reason why design issues like this should be discussed
> early. Was there an email about having the frontend emit inline
> assembly early on? If so, sorry I missed it.
>
> I still don't think we should have code where the FE emits inline
> assembly. Anything that clang can know about mips16/mips32, llvm can
> too. If llvm knows it, all that should be necessary is an attribute in
> the function saying "this is a mips32 stub".
>
>> The only annoying part are these #APP/#NOAPP wrappers.
>
> Cheers,
> Rafael
>