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
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
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
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
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.
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
>> 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
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
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
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
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.
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
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
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
I was more concerned with the term "inline asm".
-eric