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

[Reed Kotler]

I think that it's possible to do these stubs with clever calling 
conventions.

I have to add one calling convention anyway to handle the returns 
properly since those use helper functions with a different calling 
convention

I have not added a new calling convention yet so when I do and 
understand better how that works, I'll revisit some things to see if 
it's possible to do these stubs that way.

On 04/24/2013 05:24 PM, Reed Kotler wrote:
> 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
>>