search for: noapp

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

On 6 May 2013 10:29, reed kotler <rkotler at mips.com> 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 > comme...

On 05/06/2013 07:52 AM, Rafael Espíndola wrote: > On 6 May 2013 10:29, reed kotler <rkotler at mips.com> 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 t...

----- Original Message ----- > On 05/06/2013 07:52 AM, Rafael Espíndola wrote: > > On 6 May 2013 10:29, reed kotler <rkotler at mips.com> 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 st...

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

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 l...

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 generatin...

> 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

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

> 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 outpu...

...ith 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; 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...

...; 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 >> assemb...

...te: >> 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...

...ate 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 &gt...

On 24 April 2013 18:30, reed kotler <rkotler at mips.com> wrote: > There are a lot of issues. > > For one, the function I'm compiling is a mips16 function but the stubs being > created are mips32 functions. > This looks similar to thumb x 32 bit arm. Wouldn't a similar solution work for it? Cheers, Rafael

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

...y 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 followi...

...;> 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 w...

...n't think we should have code where the FE emits inline assembly. Anything that clang can know about mips16/mips32, llvm can too. If llvm knows it, all that should be necessary is an attribute in the function saying "this is a mips32 stub". > The only annoying part are these #APP/#NOAPP wrappers. Cheers, Rafael