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 > <mailto: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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130516/0ead2f2f/attachment.html>
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
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. > > -ericRight. 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