similar to: [LLVMdev] Definition of the bitcast instruction for vectors

On Fri, Aug 16, 2013 at 7:51 AM, Daniel Sanders <Daniel.Sanders at imgtec.com>wrote: > Hi,**** > > ** ** > > From http://llvm.org/docs/LangRef.html#bitcast-to-instruction:**** > > ** ** > > The ‘bitcast‘ instruction converts value to type ty2. It is always a no-op > cast because no bits change with this conversion. The conversion is done as > if the value

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

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

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,

> 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

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

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 —

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?

> > Other big-endian targets may have similar issues, but I know virtually > > nothing about them. > > ARM's is an interesting implementation of big-endian vectors. AFAIK, other > architectures go all in and use both big-endian lanes and elements. That > makes the problem go away, and you only need one load instruction. The recently published MIPS SIMD Architecture

This might help: http://llvm.org/docs/ProgrammersManual.html#the-value-class Or maybe I'm misunderstanding what you mean by "efficient way to get the value". When you say 'value', I'm assuming you mean the class. In your case, AllocaInst inherits from value. -Ryan On Thu, Dec 15, 2016 at 10:24 AM, Shen Liu via llvm-dev < llvm-dev at lists.llvm.org> wrote: >

Hi everyone, This is a simple question but is there an efficient way to get the *value for casting* directly from a bitcast instruction? bitcast format :<result> = bitcast <ty> <*value*> to <ty2> For example, if i have MemAddr ... 0x3d61238 %key = alloca [16 x i8], align 16 0x3d612a8 %plain_text = alloca [64 x i8], align 16 0x3d61318 %key1 = bitcast [16 x i8]*

Hi everyone, This is a simple question but is there an efficient way to get the value directly from a bitcast instruction? <result> = bitcast <ty> <value> to <ty2> For example, if i have MemAddr ... 0x3d61238 %key = alloca [16 x i8], align 16 0x3d612a8 %plain_text = alloca [64 x i8], align 16 0x3d61318 %key1 = bitcast [16 x i8]* %key to i8* ... The way i am using

On Aug 12, 2013, at 7:06 AM, Daniel Sanders <Daniel.Sanders at imgtec.com> wrote: >>> Other big-endian targets may have similar issues, but I know virtually >>> nothing about them. >> >> ARM's is an interesting implementation of big-endian vectors. AFAIK, other >> architectures go all in and use both big-endian lanes and elements. That >> makes

From: Villmow, Micah Sent: Tuesday, September 11, 2012 12:51 PM To: llvm-commits at cs.uiuc.edu Subject: Proposal: New IR instruction for casting between address spaces Problem: Bit casting between pointers of different address spaces only works if all address space pointers are the same size. With changes from email chain [1][2], support for different pointer sizes breaks the bitcast instruction

Hi Daniel,    Thank you your replying.     Yes, the problem is about MIPS backend. You give me this message "There is limited support for the <8 x f16> type when MSA (MIPS SIMD Architecture) is enabled but even then scalar half-precision is not currently supported."  Could you give me some official link or some evidence? Thank you very much. Robin yalong at multicorewareinc.com

Hi Ryan, Thanks for your reply! Yes i can use llvm::Use.get() API to do this, i just want to know whether there's a better way(e.g. an existed API like getValue()) to make my code look more professional. On Thu, Dec 15, 2016 at 2:58 PM, Ryan Taylor via llvm-dev < llvm-dev at lists.llvm.org> wrote: > This might help: > >

I guess I didn't understand your question, my point was that the operand, in your example, inherits from value class, it already is a value, most everything in IR is a value. -Ryan On Thu, Dec 15, 2016 at 3:10 PM, Shen Liu <sxl463 at cse.psu.edu> wrote: > Hi Ryan, > > Thanks for your reply! Yes i can use llvm::Use.get() API to do this, i > just want to know whether

On Sep 11, 2012, at 1:03 PM, "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > > From: Villmow, Micah > Sent: Tuesday, September 11, 2012 12:51 PM > To: llvm-commits at cs.uiuc.edu > Subject: Proposal: New IR instruction for casting between address spaces > > Problem: > Bit casting between pointers of different address spaces only works if all

> On Dec 15, 2016, at 12:10 PM, Shen Liu via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Ryan, > > Thanks for your reply! Yes i can use llvm::Use.get() API to do this, i just want to know whether there's a better way(e.g. an existed API like getValue()) to make my code look more professional. CastInst->getOperand(0) ? — Mehdi > > On Thu, Dec