similar to: [LLVMdev] #APP/#NOAPP

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 >

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

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

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

On Mon, May 6, 2013 at 3:08 PM, reed kotler <rkotler at mips.com> 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

On 05/06/2013 04:23 PM, Eric Christopher wrote: > On Mon, May 6, 2013 at 3:08 PM, reed kotler <rkotler at mips.com> 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

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 <rkotler at mips.com> wrote: > On 05/06/2013 04:23 PM, Eric Christopher wrote: >> >> On

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 line is enclosed by this

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

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

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

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.

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

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

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. On 04/24/2013 03:25 PM, Rafael Espíndola wrote: > 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

> 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

On 04/24/2013 03:47 PM, Rafael Espíndola wrote: > 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

> We also wanted the stubs to be real functions to llvm. That allows them to > participate properly > in optimization of various levels (including LTO). They can even be inlined. > There are other > planned optimizations that would not work if they were not legitimate > functions. I am not saying that the functions should not exist in the IL, just that they should not be inline

> 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'm happy to send you my patch as it stands today. It's not cleaned up yet all or tested thoroughtly but you can look at what I'm doing and maybe suggest some alternate paths and if it's not a matter of redoing everything, I would consider making some changes. Here is a sample stub: Consider this line of code: extern float fpff(float); We have no idea if this is a mips16 or