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

[reed kotler]

On 04/24/2013 03:47 PM, Rafael Espíndola wrote:
> On 24 April 2013 18:30, reed kotler <rkotler at mips.com> wrote:
>> There are a lot of issues.
>>
>> For one, the function I'm compiling is a mips16 function but the stubs being
>> created are mips32 functions.
>>
> This looks similar to thumb x 32 bit arm. Wouldn't a similar solution
> work for it?
>
> Cheers,
> Rafael
I'm sure there are other ways to do this. Akira and I discussed this at 
great length and decided
to do this with IR because it seemed much cleaner and had lots advantages.

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.

We already needed to implement the ability, which gcc has, to have 
mips16 and mips32 functions in the same source module, so with that 
capability, this other work was nearly trivial.
This pass I wrote is very easy to understand if you understand the 
underlying issues it is
addressing. 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.

This mips16 and mips32 floating point interoperability is very 
complicated and has many cases, compounded by messy issues with endian, 
static/pic. Mips16 has no floating point but the ABI has things being 
passed and returned in floating point registers. I don't know what 
requirements ARM thumb 1 has in this area. The Mips32 code that is 
interacting in this case
is not soft float; i.e. it's passing parameters and receiving return 
values in floating point
registers.

I'm almost done now and not going to revisit the whole design at this point.

The only annoying part are these #APP/#NOAPP wrappers.