llvm dev - Apr 2013 - [LLVMdev] issues with InlineAsm class and #APP/#NOAPP

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.

On 04/24/2013 03:25 PM, Rafael Espíndola wrote:
> compiler generated inline assembly looks odd. What is it that prevents
> the llvm backend from printing the assembly you need for the stubs?
>
> On 24 April 2013 17:58, reed kotler <rkotler at mips.com> wrote:
>> When the compiler emits assembly code in gcc, there is no #APP/#NOAPP
>>
>> In my case, I'm creating inline assembly IR as part of the
compilation
>> process (not user supplied).
>>
>> These are for compiler generated stubs.
>>
>> So I'm seeing these #APP,#NOAPP wrappers which are meant for user
inline
>> assembly.
>> Since I'm generating a lot of inline assembly and then each line is
enclosed
>> by this pair, it makes it hard to read the stubs and gcc generated
stubs do
>> not have them. Yes, I could buffer them and generate one long string
but
>> still that long string will have this wrapper and that's already
more work .
>>
>> It's not hard for me to  disable the wrappers by extending our Mips
derived
>> version of MCAsmInfo but it seems like this should be solved more
generally
>> for everyone. I'm generating a whole stub and not misc. asm code so
I can do
>> this easily but in other cases it would not be possible if things were
>> inserted in the middle of other code.
>>
>> One way would be to add a field to InlineAsm which says whether the
compiler
>> or user has requested the inline asm.
>>
>> Then we need to similarly do something different when the IR is lowered
to
>> preserve this
>> information.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

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

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.