similar to: [GlobalISel] A Proposal for global instruction selection

----- Original Message ----- > From: "James Molloy" <james at jamesmolloy.co.uk> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "llvm-dev" <llvm-dev at lists.llvm.org>, "Quentin Colombet" <qcolombet at apple.com> > Sent: Wednesday, January 13, 2016 9:54:26 AM > Subject: Re: [llvm-dev] [GlobalISel] A Proposal for global

> (Right?) Uh no, the register content explicitly does change :( We insert REV instructions (byteswap) on each bitcast. Bitcasts can be merged and elided etc, but conceptually there's a register content change on every bitcast. James On Wed, 13 Jan 2016 at 18:09 Philip Reames <listmail at philipreames.com> wrote: > > > On 01/13/2016 08:01 AM, Hal Finkel via llvm-dev

> Ok. Then we need to change the LangRef as suggested. Given this is a rather important semantic change, I think you need to send a top level RFC to the list. FWIW, I don't think this is a semantic change to LLVM-IR itself. I think it's more clearing up the misconception that LLVM-IR semantics also apply to SelectionDAG's operations. That said, I do think it's important to

This explanation makes a lot more sense to me. I think it would make sense to document this mental model, but I agree that this interpretation does not seem to require changes to the IR semantics. Just to check, this implies that DSE *is* legal right? Philip On 01/14/2016 05:48 AM, James Molloy wrote: > Hi, > > I've given a bit of misinformation here and have caused some >

Hi, > "It is always a no-op cast because no bits change with this conversion. The conversion is done as if the value had been stored to memory and read back as type ty2." I think a simple "as-if" in there should be sufficient; "It is always a no-op cast because it acts as if no bits change with this conversion. The conversion is done as if the value had been stored

> Hi Philip, > > > I think after reading your link I'm actually more confused. This might just be a wording problem, but let me ask a couple of clarifying questions. > > Sorry about that :( Every time I explain this I get slightly more embarassed because it is indeed weird and ugly (but was certainly the least ugly solution). > > > 1) After compiling the code

Hi James, I am also confused! > On Jan 12, 2016, at 4:11 PM, Philip Reames <listmail at philipreames.com> wrote: > > I think after reading your link I'm actually more confused. This might just be a wording problem, but let me ask a couple of clarifying questions. > > 1) After compiling the code sequence below (from that page), does the in memory bit pattern differ?

Hi, > I found this thinking quite difficult to explain. Does it make sense? It might help to link to the documentation on why bitcasts are weird on big-endian NEON: http://llvm.org/docs/BigEndianNEON.html#bitconverts Cheers, James On Tue, 12 Jan 2016 at 13:23 Daniel Sanders via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > > > I haven't found much time to

What happens when you cascade bitcast? Are these sequences all equivalent at the IR level (i.e. do they reference the same byte from the original i128)? i128 => <16 x i8> => GEP 0 i128 => <2 x i64> => GEP 0 => <8 x i8> => GEP 0 i128 => <2 x i64> => GEP 0 => <2 x i32> => GEP 0 => <4 x i8> => GEP 0 —

> On Jan 8, 2016, at 1:34 AM, David Chisnall via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 7 Jan 2016, at 19:47, Quentin Colombet <qcolombet at apple.com> wrote: >> >> Indeed, you said that inttoptr instruction is not a no-op on your architecture, whereas the language reference says: >> “The ‘inttoptr‘ instruction converts value to type ty2 by

Hi Daniel, Thanks for the pointers, I wasn’t aware of the second thread you’ve mentioned. I may be wrong but I think LLVM-IR optimizations really treat bistcasts as no-op casts, in the sense of no instructions are required. Is there anyone that could chime in on that? However, it seems SelectionDAG sticks to the load/store semantic: "BITCAST - This operator converts between integer,

Hi David, I had a quick look at the inttoptr/ptrtoint thing for GlobalISel and unless I am mistaken the semantic you want for such instructions do not match what the language reference says. Indeed, you said that inttoptr instruction is not a no-op on your architecture, whereas the language reference says: “The ‘inttoptr‘ instruction converts value to type ty2 by applying either a zero extension

Hi Oliver, Thanks for trying this. Could you file a different PR for each of the problem you found and reference the umbrella PR: http://llvm.org/PR35347? <http://llvm.org/PR35347?> Thanks, -Quentin > On Nov 17, 2017, at 8:17 AM, Oliver Stannard <oliver.stannard at arm.com> wrote: > > Hi Quentin, > > One more reproducer, this time with small (<64bit) values

Thanks all. Amara, could you take a look? > On Nov 20, 2017, at 3:06 AM, Oliver Stannard <oliver.stannard at arm.com> wrote: > > Hi Quentin, > > I’ve raised: > https://bugs.llvm.org/show_bug.cgi?id=35359 <https://bugs.llvm.org/show_bug.cgi?id=35359> > https://bugs.llvm.org/show_bug.cgi?id=35360 <https://bugs.llvm.org/show_bug.cgi?id=35360> >

To give an update here, we actually are not missing a mapping. The code complains because we are copying around a fp16 into a gpr32 and that shouldn’t be done with a copy (default mapping). I extended the repairing code to issue G_ANYEXT in those cases instead of asserting. However, now, I have to teach instruction select about those ANYEXT otherwise we’ll fallback in that case. But that’s a

> On Nov 19, 2015, at 9:50 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > > On 19 Nov 2015, at 17:49, Quentin Colombet <qcolombet at apple.com> wrote: >> >> I must miss something, but I don’t get what is the problem of lower the pointer to actual integer. > > Pointers, in our architecture, are not integers. Thanks for the clarifications. So

Hi Daniel, I had a quick look at the language reference for bitcast and I have a different reading than what you were pointing out. Indeed, my take away is: "It is always a no-op cast because no bits change with this conversion." In other words, deleting all bitcast instructions should be fine. My understanding of the quote you’ve highlighted is that it tells C programmers that this

Hi, I experienced a crash in code compiled with Clang 10.0.0 due to a misaligned 64-bit data access. The (ARMv8) CPU is configured with SCTL.A == 1 (alignment check enable). With SCTLR.A == 0 the code runs as expected. After some investigation I came up with the following reproducer: ---8<-------8<-------8<-------8<-------8<-------8<-------8<------- $ cat test.c extern char

On Sep 6, 2012, at 4:40 PM, David Peixotto <dpeixott at codeaurora.org> wrote: > -----Original Message----- > From: Bob Wilson [mailto:bob.wilson at apple.com] > Sent: Thursday, September 06, 2012 3:39 PM > To: David Peixotto > Cc: 'Peter Couperus'; 'Jim Grosbach'; 'Jakob Olesen'; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Unaligned vector

Hi Kristof, > On Apr 6, 2017, at 6:53 AM, Kristof Beyls <kristof.beyls at arm.com> wrote: > > I've been digging a little bit deeper into the biggest performance regressions I've observed. > > What I've observed so far is: > * A lot of the biggest regressions are caused by unnecessarily moving floating point values through general purpose registers. I've