[LLVMdev] #APP/#NOAPP

[Eric Christopher]

On Thu, May 16, 2013 at 3:06 PM, reed kotler <rkotler at mips.com> wrote:
> On 05/16/2013 10:06 AM, Eric Christopher wrote:
>>
>> On Thu, May 16, 2013 at 3:17 AM, reed kotler <rkotler at mips.com> wrote:
>>>
>>> On 05/15/2013 10:53 PM, Richard Smith wrote:
>>>
>>> On Mon, May 6, 2013 at 9:09 AM, reed kotler <rkotler at mips.com> wrote:
>>>>
>>>> On 05/06/2013 08:51 AM, Rafael Espíndola wrote:
>>>>>>
>>>>>> It's working fine just that it's ugly to see those APP/NOAPP markers.
>>>>>
>>>>> Inline assembly is inline assembly. It has the semantics defined in
>>>>> the IL documentation and should all be treated uniformly.
>>>>>
>>>>> I guess I would be OK with unconditionally removing those comments (I
>>>>> don't see a lot of value in them) or having different verbosity levels
>>>>> for the asm output.
>>>>>
>>>>> What we should never have is a "if (this asm was created by llvm
>>>>> itself)".
>>>>
>>>> I would like to see a method in asm printer which turns on/off these
>>>> comments.
>>>> It's trivial to add and use but I can't put back to this code without
>>>> permission so there is no point to write the patch if nobody will
>>>> approve
>>>> it.
>>>>
>>>> Then I could call that method when I'm processing  compiler generated
>>>> stubs that have inline
>>>> assembly.
>>>>
>>>> Traditionally these comments are used in gcc so that when you look at
>>>> assembly code, you can tell which was generated by the compiler and
>>>> which
>>>> was inline assembly the user created.
>>>
>>>
>>> This does not appear to be the case. As far as I can discern from the
>>> available documentation, #APP and #NOAPP are pragmas which inform the
>>> assembler's preprocessor whether it's in "application mode" (where it
>>> needs
>>> more expensive tokenization rules, including comment-stripping and the
>>> like)
>>> or whether it's in "processing compiler output mode" (where it can skip
>>> all
>>> that stuff).
>>>
>>> That these pragmas *also* mark where the user's inline asm ended up seems
>>> to
>>> just be a happy coincidence.
>>>
>>>
>>> I've read that too in the docs but I don't think it has any meaning here
>>> because I'm emitting the same kind of code that gcc emits; so I should
>>> not
>>> need them. Possible it slows down compilation by some
>>> tiny amount here.
>>>
>>> It does not hurt for me to have the APP/NO_APP markers; I just don't like
>>> to
>>> see them in the .s file.
>>> As Jim Grosbach and others have noted, if I move the inline asm
>>> generation
>>> to another place, I won't get those. It's just because the compiler is
>>> doing
>>> what I user would do that I'm getting them.
>>>
>> I would like to re-emphasize that you're not generating inline asm (or
>> well you shouldn't be) - you're generating a call stub and
>> interworking code between two ISAs. It's a very important distinction.
>>
>> -eric
>
> Right. I'm generating stubs for interworking between mips16 and mips32 when
> floating point registers are used in the call or return.
>
> I've said that in my emails but used the word interoperability instead of
> interworking.
>
> I will use interworking from now on because it seems to be a more well
> accepted word for that.
>

I was more concerned with the term "inline asm".

-eric