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

[reed kotler]

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