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

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.

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

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