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

Rafael EspĂ­ndola rafael.espindola at gmail.com
Wed Apr 24 15:25:57 PDT 2013


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



More information about the llvm-dev mailing list