#APP/#NOAPP

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

#APP/#NOAPP

Reed Kotler
I want to disable the #APP/#NOAPP for compiler generated inline asm.

Unfortunately, you can change the string APP,NOAPP, but it still will
put the "#" there and create
a line.

In the comments it said that the strings were #APP,#NOAPP but really
it's just the part after the
comment_string=='#'

I'd like to just add a mode flag to AsmPrinter for this.

Any objections?

Alternately I could change the logic in AsmPrinter to not print a line
if the inlline asm start/end string is null.

????

TIA.

Reed


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: #APP/#NOAPP

Rafael Espíndola
On 6 May 2013 10:29, reed kotler <[hidden email]> wrote:

> I want to disable the #APP/#NOAPP for compiler generated inline asm.
>
> Unfortunately, you can change the string APP,NOAPP, but it still will put
> the "#" there and create
> a line.
>
> In the comments it said that the strings were #APP,#NOAPP but really it's
> just the part after the
> comment_string=='#'
>
> I'd like to just add a mode flag to AsmPrinter for this.
>
> Any objections?

Yes.  I don't think we should introduce the notion of "compiler
generated inline asm".

> Alternately I could change the logic in AsmPrinter to not print a line if
> the inlline asm start/end string is null.
>
> ????
>
> TIA.
>
> Reed
>

Cheers,
Rafael
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: #APP/#NOAPP

Reed Kotler
On 05/06/2013 07:52 AM, Rafael Espíndola wrote:

> On 6 May 2013 10:29, reed kotler <[hidden email]> wrote:
>> I want to disable the #APP/#NOAPP for compiler generated inline asm.
>>
>> Unfortunately, you can change the string APP,NOAPP, but it still will put
>> the "#" there and create
>> a line.
>>
>> In the comments it said that the strings were #APP,#NOAPP but really it's
>> just the part after the
>> comment_string=='#'
>>
>> I'd like to just add a mode flag to AsmPrinter for this.
>>
>> Any objections?
> Yes.  I don't think we should introduce the notion of "compiler
> generated inline asm".
Hi Rafael,

At this time I have to generate compiler stubs for mips16/32 floating
point interoperability and I've already implemented it all and I did it
by generating inline assembly in a module pass.

The whole problem this is solving is complicated and has many cases and
my solution was very clean and easy to understand.

It's all in the Mips port and I don't have to time or desire to redo the
whole thing right now.

It's working fine just that it's ugly to see those APP/NOAPP markers.

I think that I can actually replace the inline assembly for these
particular stubs with some non inline asm using special calling
conventions but I don't want to do that right now. I've filed a local
bug at mips against myself to do that work. There are some further
issues here but Akira and I think
it's certainly doable.

I want to finish testing and checking in what I have and then will work
on improvements later.

There are many things to still do for mips 16 and this part already is
done and works as in gcc.
I'm still debugging and writing test cases.

I think that it's perfectly valid to generate inline assembler and it
looks 1000 times cleaner than if I tried to do this same work with
selection DAG.

There are other stubs to be created for other parts of the mips32 port.

So I'd like to get a solution to these ugly APP/NOAPP markers.

Maybe you would not do things this way but I think it's a perfectly
valid approach.
No two people have 100% the same idea of what is best practices.

The following kind of patch works without adding a mode to asm printer
but in general is harder
for people to use since they have to get a hook to MCAsm in order to
change the inline_asm_start/end
strings. (In AsmPrinter) on a per function basis.

   if (OutStreamer.hasRawTextSupport() && MAI->getInlineAsmStart()[0])
     OutStreamer.EmitRawText(Twine("\t")+MAI->getCommentString()+
                             MAI->getInlineAsmStart());

So a simple method in AsmPrinter would be the easiest for people to use.

It just turns off the APP/NOAPP markers which we should be able to do
anyway; it's independent of the discussion regarding the goodness or not
of the compiler emitting inline assembly.


Reed



>> Alternately I could change the logic in AsmPrinter to not print a line if
>> the inlline asm start/end string is null.
>>
>> ????
>>
>> TIA.
>>
>> Reed
>>
> Cheers,
> Rafael


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: #APP/#NOAPP

Rafael Espíndola
> 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)".

Cheers,
Rafael
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: #APP/#NOAPP

Reed Kotler
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.

People writing inline assembly tend to write multi-line strings for the
inline asm block so they don't have so many of these wrappers as I do.

I'm generating a line at a time.

Adding additional compiler options is another issue.

If you just turned these comments all off right now, I think that "make
check" would fail a lot because people are looking for these markers in
some tests.


> Cheers,
> Rafael


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: #APP/#NOAPP

Rafael Espíndola
> Then I could call that method when I'm processing  compiler generated stubs
> that have inline
> assembly.

Sorry, I just think this is a way too slippery slope to be in. People
already misunderstand and misuse hasRawTextSupport. Adding the ability
to for llvm to know if an inline assembly is human written or machine
generated would be a massive foot gun.

Cheers,
Rafael
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: #APP/#NOAPP

Reed Kotler
On 05/06/2013 09:13 AM, Rafael Espíndola wrote:

>> Then I could call that method when I'm processing  compiler generated stubs
>> that have inline
>> assembly.
> Sorry, I just think this is a way too slippery slope to be in. People
> already misunderstand and misuse hasRawTextSupport. Adding the ability
> to for llvm to know if an inline assembly is human written or machine
> generated would be a massive foot gun.
>
> Cheers,
> Rafael
I think you are mixing up lots of things here.

The ability to turn on /off these APP/NOAPP markers is something
independent  of anything having to do with compiler generated inline asm
or being able to tell how asm is generated.

So now I will generate ugly looking asm output that is harder for me to
debug and look at it.

What is that helping?

It's a 10 line patch that has no effect on anything but the Mips port
but the functionality is there now for others that need it.

I personally would be happy to remove APP/NOAPP but that is what gcc
does too and you will break many tests in llvm "make check" if you do that.

When gcc emits stubs for mips16/32 interoperability, there are no
APP/NOAPP comments in it.
How am I supposed to match that if I'm prevented from disabling those?

Reed







_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: #APP/#NOAPP

Hal Finkel
In reply to this post by Reed Kotler
----- Original Message -----

> On 05/06/2013 07:52 AM, Rafael Espíndola wrote:
> > On 6 May 2013 10:29, reed kotler <[hidden email]> wrote:
> >> I want to disable the #APP/#NOAPP for compiler generated inline
> >> asm.
> >>
> >> Unfortunately, you can change the string APP,NOAPP, but it still
> >> will put
> >> the "#" there and create
> >> a line.
> >>
> >> In the comments it said that the strings were #APP,#NOAPP but
> >> really it's
> >> just the part after the
> >> comment_string=='#'
> >>
> >> I'd like to just add a mode flag to AsmPrinter for this.
> >>
> >> Any objections?
> > Yes.  I don't think we should introduce the notion of "compiler
> > generated inline asm".
> Hi Rafael,
>
> At this time I have to generate compiler stubs for mips16/32 floating
> point interoperability and I've already implemented it all and I did
> it
> by generating inline assembly in a module pass.
>
> The whole problem this is solving is complicated and has many cases
> and
> my solution was very clean and easy to understand.
>
> It's all in the Mips port and I don't have to time or desire to redo
> the
> whole thing right now.
>
> It's working fine just that it's ugly to see those APP/NOAPP markers.
>
> I think that I can actually replace the inline assembly for these
> particular stubs with some non inline asm using special calling
> conventions but I don't want to do that right now. I've filed a local
> bug at mips against myself to do that work. There are some further
> issues here but Akira and I think
> it's certainly doable.
>
> I want to finish testing and checking in what I have and then will
> work
> on improvements later.
>
> There are many things to still do for mips 16 and this part already
> is
> done and works as in gcc.
> I'm still debugging and writing test cases.
>
> I think that it's perfectly valid to generate inline assembler and it
> looks 1000 times cleaner than if I tried to do this same work with
> selection DAG.

I hope you don't mind if I play devil's advocate here...

Why is this so complicated that it would be messy to do, at least in part, at a lower level? I can understand needing IR-level analysis for some kinds of transformations, but late IR-level passes can insert target-specific intrinsics, those can be matched to pseudo instructions, and those pseudo instructions can be expanded (as late as necessary) by a custom inserter. I agree that this may add more boiler-plate work, but it is not immediately obvious why this would be 1000x messier.

 -Hal

>
> There are other stubs to be created for other parts of the mips32
> port.
>
> So I'd like to get a solution to these ugly APP/NOAPP markers.
>
> Maybe you would not do things this way but I think it's a perfectly
> valid approach.
> No two people have 100% the same idea of what is best practices.
>
> The following kind of patch works without adding a mode to asm
> printer
> but in general is harder
> for people to use since they have to get a hook to MCAsm in order to
> change the inline_asm_start/end
> strings. (In AsmPrinter) on a per function basis.
>
>    if (OutStreamer.hasRawTextSupport() &&
>    MAI->getInlineAsmStart()[0])
>      OutStreamer.EmitRawText(Twine("\t")+MAI->getCommentString()+
>                              MAI->getInlineAsmStart());
>
> So a simple method in AsmPrinter would be the easiest for people to
> use.
>
> It just turns off the APP/NOAPP markers which we should be able to do
> anyway; it's independent of the discussion regarding the goodness or
> not
> of the compiler emitting inline assembly.
>
>
> Reed
>
>
>
> >> Alternately I could change the logic in AsmPrinter to not print a
> >> line if
> >> the inlline asm start/end string is null.
> >>
> >> ????
> >>
> >> TIA.
> >>
> >> Reed
> >>
> > Cheers,
> > Rafael
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: #APP/#NOAPP

Reed Kotler
Hi Hal,

I think that it's perfectly valid to generate inline assembler and it
looks 1000 times cleaner than if I tried to do this same work with
selection DAG.

> I hope you don't mind if I play devil's advocate here...
>
> Why is this so complicated that it would be messy to do, at least in part, at a lower level? I can understand needing IR-level analysis for some kinds of transformations, but late IR-level passes can insert target-specific intrinsics, those can be matched to pseudo instructions, and those pseudo instructions can be expanded (as late as necessary) by a custom inserter. I agree that this may add more boiler-plate work, but it is not immediately obvious why this would be 1000x messier.
>
>   -Hal
I should probably qualify this with "1000 times messier for me" :)

In this case the whole problem fit neatly in a simple IR level module pass.

I had to create an alternate calling convention for one part but
otherwise this IR
pass made an otherwise very messy problem easy to implement.

Reed

>> There are other stubs to be created for other parts of the mips32
>> port.
>>
>> So I'd like to get a solution to these ugly APP/NOAPP markers.
>>
>> Maybe you would not do things this way but I think it's a perfectly
>> valid approach.
>> No two people have 100% the same idea of what is best practices.
>>
>> The following kind of patch works without adding a mode to asm
>> printer
>> but in general is harder
>> for people to use since they have to get a hook to MCAsm in order to
>> change the inline_asm_start/end
>> strings. (In AsmPrinter) on a per function basis.
>>
>>     if (OutStreamer.hasRawTextSupport() &&
>>     MAI->getInlineAsmStart()[0])
>>       OutStreamer.EmitRawText(Twine("\t")+MAI->getCommentString()+
>>                               MAI->getInlineAsmStart());
>>
>> So a simple method in AsmPrinter would be the easiest for people to
>> use.
>>
>> It just turns off the APP/NOAPP markers which we should be able to do
>> anyway; it's independent of the discussion regarding the goodness or
>> not
>> of the compiler emitting inline assembly.
>>
>>
>> Reed
>>
>>
>>
>>>> Alternately I could change the logic in AsmPrinter to not print a
>>>> line if
>>>> the inlline asm start/end string is null.
>>>>
>>>> ????
>>>>
>>>> TIA.
>>>>
>>>> Reed
>>>>
>>> Cheers,
>>> Rafael
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: #APP/#NOAPP

Eric Christopher
On Mon, May 6, 2013 at 3:08 PM, reed kotler <[hidden email]> wrote:
> Hi Hal,
>
>
> I think that it's perfectly valid to generate inline assembler and it
> looks 1000 times cleaner than if I tried to do this same work with
> selection DAG.
>

I'm pretty sure you're the only one who thinks this. What's so
complicated about doing this either at selection dag or MI lowering
time?

-eric

>> I hope you don't mind if I play devil's advocate here...
>>
>> Why is this so complicated that it would be messy to do, at least in part,
>> at a lower level? I can understand needing IR-level analysis for some kinds
>> of transformations, but late IR-level passes can insert target-specific
>> intrinsics, those can be matched to pseudo instructions, and those pseudo
>> instructions can be expanded (as late as necessary) by a custom inserter. I
>> agree that this may add more boiler-plate work, but it is not immediately
>> obvious why this would be 1000x messier.
>>
>>   -Hal
>
> I should probably qualify this with "1000 times messier for me" :)
>
> In this case the whole problem fit neatly in a simple IR level module pass.
>
> I had to create an alternate calling convention for one part but otherwise
> this IR
> pass made an otherwise very messy problem easy to implement.
>
> Reed
>
>
>>> There are other stubs to be created for other parts of the mips32
>>> port.
>>>
>>> So I'd like to get a solution to these ugly APP/NOAPP markers.
>>>
>>> Maybe you would not do things this way but I think it's a perfectly
>>> valid approach.
>>> No two people have 100% the same idea of what is best practices.
>>>
>>> The following kind of patch works without adding a mode to asm
>>> printer
>>> but in general is harder
>>> for people to use since they have to get a hook to MCAsm in order to
>>> change the inline_asm_start/end
>>> strings. (In AsmPrinter) on a per function basis.
>>>
>>>     if (OutStreamer.hasRawTextSupport() &&
>>>     MAI->getInlineAsmStart()[0])
>>>       OutStreamer.EmitRawText(Twine("\t")+MAI->getCommentString()+
>>>                               MAI->getInlineAsmStart());
>>>
>>> So a simple method in AsmPrinter would be the easiest for people to
>>> use.
>>>
>>> It just turns off the APP/NOAPP markers which we should be able to do
>>> anyway; it's independent of the discussion regarding the goodness or
>>> not
>>> of the compiler emitting inline assembly.
>>>
>>>
>>> Reed
>>>
>>>
>>>
>>>>> Alternately I could change the logic in AsmPrinter to not print a
>>>>> line if
>>>>> the inlline asm start/end string is null.
>>>>>
>>>>> ????
>>>>>
>>>>> TIA.
>>>>>
>>>>> Reed
>>>>>
>>>> Cheers,
>>>> Rafael
>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> [hidden email]         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: #APP/#NOAPP

Reed Kotler
On 05/06/2013 04:23 PM, Eric Christopher wrote:

> On Mon, May 6, 2013 at 3:08 PM, reed kotler <[hidden email]> wrote:
>> Hi Hal,
>>
>>
>> I think that it's perfectly valid to generate inline assembler and it
>> looks 1000 times cleaner than if I tried to do this same work with
>> selection DAG.
>>
> I'm pretty sure you're the only one who thinks this. What's so
> complicated about doing this either at selection dag or MI lowering
> time?
>
> -eric
>
This pass I did was very easy for me to do in IR. It took maybe a week
to write which included time for analysis (what I'm doing is mimicking
gcc and how it does this is not documented).

There are lots of cases to handle and it took very little code to do it.

It's possible to even eliminate half of the code by adding a new calling
convention which
I intend to do at a later time.

Someone else might have done this a different way (maybe even everyone
but me :) )

When I check it in you can look at it and maybe advise me for future
reference.
That would be great to know a better way.

There are other stubs we need to add for mips but these are the ones for
mips16/mips32 floating point interoperability.

There is also code inserted to return values in both integer and
floating point registers (for the same return) so that depending on the
callee (mips32 or mips16 mode function), the register will be where it
expects it to be.

Reed

>>> I hope you don't mind if I play devil's advocate here...
>>>
>>> Why is this so complicated that it would be messy to do, at least in part,
>>> at a lower level? I can understand needing IR-level analysis for some kinds
>>> of transformations, but late IR-level passes can insert target-specific
>>> intrinsics, those can be matched to pseudo instructions, and those pseudo
>>> instructions can be expanded (as late as necessary) by a custom inserter. I
>>> agree that this may add more boiler-plate work, but it is not immediately
>>> obvious why this would be 1000x messier.
>>>
>>>    -Hal
>> I should probably qualify this with "1000 times messier for me" :)
>>
>> In this case the whole problem fit neatly in a simple IR level module pass.
>>
>> I had to create an alternate calling convention for one part but otherwise
>> this IR
>> pass made an otherwise very messy problem easy to implement.
>>
>> Reed
>>
>>
>>>> There are other stubs to be created for other parts of the mips32
>>>> port.
>>>>
>>>> So I'd like to get a solution to these ugly APP/NOAPP markers.
>>>>
>>>> Maybe you would not do things this way but I think it's a perfectly
>>>> valid approach.
>>>> No two people have 100% the same idea of what is best practices.
>>>>
>>>> The following kind of patch works without adding a mode to asm
>>>> printer
>>>> but in general is harder
>>>> for people to use since they have to get a hook to MCAsm in order to
>>>> change the inline_asm_start/end
>>>> strings. (In AsmPrinter) on a per function basis.
>>>>
>>>>      if (OutStreamer.hasRawTextSupport() &&
>>>>      MAI->getInlineAsmStart()[0])
>>>>        OutStreamer.EmitRawText(Twine("\t")+MAI->getCommentString()+
>>>>                                MAI->getInlineAsmStart());
>>>>
>>>> So a simple method in AsmPrinter would be the easiest for people to
>>>> use.
>>>>
>>>> It just turns off the APP/NOAPP markers which we should be able to do
>>>> anyway; it's independent of the discussion regarding the goodness or
>>>> not
>>>> of the compiler emitting inline assembly.
>>>>
>>>>
>>>> Reed
>>>>
>>>>
>>>>
>>>>>> Alternately I could change the logic in AsmPrinter to not print a
>>>>>> line if
>>>>>> the inlline asm start/end string is null.
>>>>>>
>>>>>> ????
>>>>>>
>>>>>> TIA.
>>>>>>
>>>>>> Reed
>>>>>>
>>>>> Cheers,
>>>>> Rafael
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> [hidden email]         http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: #APP/#NOAPP

Reed Kotler
In reply to this post by Eric Christopher
On 05/06/2013 04:23 PM, Eric Christopher wrote:

> On Mon, May 6, 2013 at 3:08 PM, reed kotler <[hidden email]> wrote:
>> Hi Hal,
>>
>>
>> I think that it's perfectly valid to generate inline assembler and it
>> looks 1000 times cleaner than if I tried to do this same work with
>> selection DAG.
>>
> I'm pretty sure you're the only one who thinks this. What's so
> complicated about doing this either at selection dag or MI lowering
> time?
>
> -eric
An earlier part of this I actually did do with selection DAG and it was
messy and the code was much less easy to understand than this Module IR
pass is.

  r173320

I intend to move most of this code into the new pass at a later time. It
will make it possible
to understand the whole scheme in one place.

Much of the code needs to access the IR anyway, even though it finds it
starting with the
DAG.


>>> I hope you don't mind if I play devil's advocate here...
>>>
>>> Why is this so complicated that it would be messy to do, at least in part,
>>> at a lower level? I can understand needing IR-level analysis for some kinds
>>> of transformations, but late IR-level passes can insert target-specific
>>> intrinsics, those can be matched to pseudo instructions, and those pseudo
>>> instructions can be expanded (as late as necessary) by a custom inserter. I
>>> agree that this may add more boiler-plate work, but it is not immediately
>>> obvious why this would be 1000x messier.
>>>
>>>    -Hal
>> I should probably qualify this with "1000 times messier for me" :)
>>
>> In this case the whole problem fit neatly in a simple IR level module pass.
>>
>> I had to create an alternate calling convention for one part but otherwise
>> this IR
>> pass made an otherwise very messy problem easy to implement.
>>
>> Reed
>>
>>
>>>> There are other stubs to be created for other parts of the mips32
>>>> port.
>>>>
>>>> So I'd like to get a solution to these ugly APP/NOAPP markers.
>>>>
>>>> Maybe you would not do things this way but I think it's a perfectly
>>>> valid approach.
>>>> No two people have 100% the same idea of what is best practices.
>>>>
>>>> The following kind of patch works without adding a mode to asm
>>>> printer
>>>> but in general is harder
>>>> for people to use since they have to get a hook to MCAsm in order to
>>>> change the inline_asm_start/end
>>>> strings. (In AsmPrinter) on a per function basis.
>>>>
>>>>      if (OutStreamer.hasRawTextSupport() &&
>>>>      MAI->getInlineAsmStart()[0])
>>>>        OutStreamer.EmitRawText(Twine("\t")+MAI->getCommentString()+
>>>>                                MAI->getInlineAsmStart());
>>>>
>>>> So a simple method in AsmPrinter would be the easiest for people to
>>>> use.
>>>>
>>>> It just turns off the APP/NOAPP markers which we should be able to do
>>>> anyway; it's independent of the discussion regarding the goodness or
>>>> not
>>>> of the compiler emitting inline assembly.
>>>>
>>>>
>>>> Reed
>>>>
>>>>
>>>>
>>>>>> Alternately I could change the logic in AsmPrinter to not print a
>>>>>> line if
>>>>>> the inlline asm start/end string is null.
>>>>>>
>>>>>> ????
>>>>>>
>>>>>> TIA.
>>>>>>
>>>>>> Reed
>>>>>>
>>>>> Cheers,
>>>>> Rafael
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> [hidden email]         http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: #APP/#NOAPP

Eric Christopher
That code looks a little odd but not too awful. I still don't
understand what's so wrong/complicated about this. You seem to be of
the opinion that injecting asm into a stream ala gcc is a good idea in
clang, it really isn't.

-eric

On Mon, May 6, 2013 at 5:45 PM, reed kotler <[hidden email]> wrote:

> On 05/06/2013 04:23 PM, Eric Christopher wrote:
>>
>> On Mon, May 6, 2013 at 3:08 PM, reed kotler <[hidden email]> wrote:
>>>
>>> Hi Hal,
>>>
>>>
>>> I think that it's perfectly valid to generate inline assembler and it
>>> looks 1000 times cleaner than if I tried to do this same work with
>>> selection DAG.
>>>
>> I'm pretty sure you're the only one who thinks this. What's so
>> complicated about doing this either at selection dag or MI lowering
>> time?
>>
>> -eric
>
> An earlier part of this I actually did do with selection DAG and it was
> messy and the code was much less easy to understand than this Module IR pass
> is.
>
>  r173320
>
> I intend to move most of this code into the new pass at a later time. It
> will make it possible
> to understand the whole scheme in one place.
>
> Much of the code needs to access the IR anyway, even though it finds it
> starting with the
> DAG.
>
>
>
>>>> I hope you don't mind if I play devil's advocate here...
>>>>
>>>> Why is this so complicated that it would be messy to do, at least in
>>>> part,
>>>> at a lower level? I can understand needing IR-level analysis for some
>>>> kinds
>>>> of transformations, but late IR-level passes can insert target-specific
>>>> intrinsics, those can be matched to pseudo instructions, and those
>>>> pseudo
>>>> instructions can be expanded (as late as necessary) by a custom
>>>> inserter. I
>>>> agree that this may add more boiler-plate work, but it is not
>>>> immediately
>>>> obvious why this would be 1000x messier.
>>>>
>>>>    -Hal
>>>
>>> I should probably qualify this with "1000 times messier for me" :)
>>>
>>> In this case the whole problem fit neatly in a simple IR level module
>>> pass.
>>>
>>> I had to create an alternate calling convention for one part but
>>> otherwise
>>> this IR
>>> pass made an otherwise very messy problem easy to implement.
>>>
>>> Reed
>>>
>>>
>>>>> There are other stubs to be created for other parts of the mips32
>>>>> port.
>>>>>
>>>>> So I'd like to get a solution to these ugly APP/NOAPP markers.
>>>>>
>>>>> Maybe you would not do things this way but I think it's a perfectly
>>>>> valid approach.
>>>>> No two people have 100% the same idea of what is best practices.
>>>>>
>>>>> The following kind of patch works without adding a mode to asm
>>>>> printer
>>>>> but in general is harder
>>>>> for people to use since they have to get a hook to MCAsm in order to
>>>>> change the inline_asm_start/end
>>>>> strings. (In AsmPrinter) on a per function basis.
>>>>>
>>>>>      if (OutStreamer.hasRawTextSupport() &&
>>>>>      MAI->getInlineAsmStart()[0])
>>>>>        OutStreamer.EmitRawText(Twine("\t")+MAI->getCommentString()+
>>>>>                                MAI->getInlineAsmStart());
>>>>>
>>>>> So a simple method in AsmPrinter would be the easiest for people to
>>>>> use.
>>>>>
>>>>> It just turns off the APP/NOAPP markers which we should be able to do
>>>>> anyway; it's independent of the discussion regarding the goodness or
>>>>> not
>>>>> of the compiler emitting inline assembly.
>>>>>
>>>>>
>>>>> Reed
>>>>>
>>>>>
>>>>>
>>>>>>> Alternately I could change the logic in AsmPrinter to not print a
>>>>>>> line if
>>>>>>> the inlline asm start/end string is null.
>>>>>>>
>>>>>>> ????
>>>>>>>
>>>>>>> TIA.
>>>>>>>
>>>>>>> Reed
>>>>>>>
>>>>>> Cheers,
>>>>>> Rafael
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> [hidden email]         http://llvm.cs.uiuc.edu
>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>>
>>>
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> [hidden email]         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: #APP/#NOAPP

Reed Kotler
On 05/09/2013 04:22 PM, Eric Christopher wrote:
> That code looks a little odd but not too awful. I still don't
> understand what's so wrong/complicated about this. You seem to be of
> the opinion that injecting asm into a stream ala gcc is a good idea in
> clang, it really isn't.
>
> -eric
Hi Eric,

I'm going to start putting this code back soon. It's in several patches,
the first of which does not have any inline assembly code being emitted.

It's not a huge amount of code and it's in it's own separate IR module
pass. I am doing more testing and some cleanup as a result of internal
review by Akira.

When I do, you can look at what I did and tell me how I could have done
it differently. I try and float all my ideas by the list before doing
any major work and I would have brought this up if I had thought it was
important. The emitting of the actual body of the stub is the trivial
part of this. Maybe I can move that code somewhere else. You can advise.

This interoperability between mips16/mips32 for floating point is very
complicated and by doing it they way I did, it's really easy to read the
code and see the whole thing in one place. I can't really imagine trying
to understand all of this with it spread out in the DAGISEL target
lowering code.

The stubs and the code I'm compiling are not even for the same
instruction: the code is mip16 code and the stubs are mips32.

I don't think it's an objective fact that injecting asm in the stream is
not a good idea but surely some (maybe many or most) people would agree
with you.

reed

>
> On Mon, May 6, 2013 at 5:45 PM, reed kotler <[hidden email]> wrote:
>> On 05/06/2013 04:23 PM, Eric Christopher wrote:
>>>
>>> On Mon, May 6, 2013 at 3:08 PM, reed kotler <[hidden email]> wrote:
>>>>
>>>> Hi Hal,
>>>>
>>>>
>>>> I think that it's perfectly valid to generate inline assembler and it
>>>> looks 1000 times cleaner than if I tried to do this same work with
>>>> selection DAG.
>>>>
>>> I'm pretty sure you're the only one who thinks this. What's so
>>> complicated about doing this either at selection dag or MI lowering
>>> time?
>>>
>>> -eric
>>
>> An earlier part of this I actually did do with selection DAG and it was
>> messy and the code was much less easy to understand than this Module IR pass
>> is.
>>
>>   r173320
>>
>> I intend to move most of this code into the new pass at a later time. It
>> will make it possible
>> to understand the whole scheme in one place.
>>
>> Much of the code needs to access the IR anyway, even though it finds it
>> starting with the
>> DAG.
>>
>>
>>
>>>>> I hope you don't mind if I play devil's advocate here...
>>>>>
>>>>> Why is this so complicated that it would be messy to do, at least in
>>>>> part,
>>>>> at a lower level? I can understand needing IR-level analysis for some
>>>>> kinds
>>>>> of transformations, but late IR-level passes can insert target-specific
>>>>> intrinsics, those can be matched to pseudo instructions, and those
>>>>> pseudo
>>>>> instructions can be expanded (as late as necessary) by a custom
>>>>> inserter. I
>>>>> agree that this may add more boiler-plate work, but it is not
>>>>> immediately
>>>>> obvious why this would be 1000x messier.
>>>>>
>>>>>     -Hal
>>>>
>>>> I should probably qualify this with "1000 times messier for me" :)
>>>>
>>>> In this case the whole problem fit neatly in a simple IR level module
>>>> pass.
>>>>
>>>> I had to create an alternate calling convention for one part but
>>>> otherwise
>>>> this IR
>>>> pass made an otherwise very messy problem easy to implement.
>>>>
>>>> Reed
>>>>
>>>>
>>>>>> There are other stubs to be created for other parts of the mips32
>>>>>> port.
>>>>>>
>>>>>> So I'd like to get a solution to these ugly APP/NOAPP markers.
>>>>>>
>>>>>> Maybe you would not do things this way but I think it's a perfectly
>>>>>> valid approach.
>>>>>> No two people have 100% the same idea of what is best practices.
>>>>>>
>>>>>> The following kind of patch works without adding a mode to asm
>>>>>> printer
>>>>>> but in general is harder
>>>>>> for people to use since they have to get a hook to MCAsm in order to
>>>>>> change the inline_asm_start/end
>>>>>> strings. (In AsmPrinter) on a per function basis.
>>>>>>
>>>>>>       if (OutStreamer.hasRawTextSupport() &&
>>>>>>       MAI->getInlineAsmStart()[0])
>>>>>>         OutStreamer.EmitRawText(Twine("\t")+MAI->getCommentString()+
>>>>>>                                 MAI->getInlineAsmStart());
>>>>>>
>>>>>> So a simple method in AsmPrinter would be the easiest for people to
>>>>>> use.
>>>>>>
>>>>>> It just turns off the APP/NOAPP markers which we should be able to do
>>>>>> anyway; it's independent of the discussion regarding the goodness or
>>>>>> not
>>>>>> of the compiler emitting inline assembly.
>>>>>>
>>>>>>
>>>>>> Reed
>>>>>>
>>>>>>
>>>>>>
>>>>>>>> Alternately I could change the logic in AsmPrinter to not print a
>>>>>>>> line if
>>>>>>>> the inlline asm start/end string is null.
>>>>>>>>
>>>>>>>> ????
>>>>>>>>
>>>>>>>> TIA.
>>>>>>>>
>>>>>>>> Reed
>>>>>>>>
>>>>>>> Cheers,
>>>>>>> Rafael
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> LLVM Developers mailing list
>>>>>> [hidden email]         http://llvm.cs.uiuc.edu
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>>>>
>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> [hidden email]         http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>>


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: #APP/#NOAPP

Richard Smith-33
In reply to this post by Reed Kotler
On Mon, May 6, 2013 at 9:09 AM, reed kotler <[hidden email]> 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.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: #APP/#NOAPP

Reed Kotler
On 05/15/2013 10:53 PM, Richard Smith wrote:
On Mon, May 6, 2013 at 9:09 AM, reed kotler <[hidden email]> 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.




_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: #APP/#NOAPP

Eric Christopher
On Thu, May 16, 2013 at 3:17 AM, reed kotler <[hidden email]> wrote:

> On 05/15/2013 10:53 PM, Richard Smith wrote:
>
> On Mon, May 6, 2013 at 9:09 AM, reed kotler <[hidden email]> 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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: #APP/#NOAPP

Reed Kotler
On 05/16/2013 10:06 AM, Eric Christopher wrote:

> On Thu, May 16, 2013 at 3:17 AM, reed kotler <[hidden email]> wrote:
>> On 05/15/2013 10:53 PM, Richard Smith wrote:
>>
>> On Mon, May 6, 2013 at 9:09 AM, reed kotler <[hidden email]> 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.

Reed

REed


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: #APP/#NOAPP

Eric Christopher
On Thu, May 16, 2013 at 3:06 PM, reed kotler <[hidden email]> wrote:

> On 05/16/2013 10:06 AM, Eric Christopher wrote:
>>
>> On Thu, May 16, 2013 at 3:17 AM, reed kotler <[hidden email]> wrote:
>>>
>>> On 05/15/2013 10:53 PM, Richard Smith wrote:
>>>
>>> On Mon, May 6, 2013 at 9:09 AM, reed kotler <[hidden email]> 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

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev