search for: bistcast

Hi, I didn't know that about bitcast. This becomes important if someone wants a pointer to a vector element as we would either need to support the bistcast or we just don't allow that. For most vector code that I'm aware of, no one really wants to take an address of vector element as by doing so, one is kind of scalarizing the vector which would be bad for performance. If someone has a case where this is useful, I would like to see i...

On Oct 14, 2008, at 9:50 AM, Mon Ping Wang wrote: > Hi, > > I ran into a case where ScalarReplAggregates can not promote an array > of vectors into registers, e..g, > %a = alloca [8 x <2 x float>], align 8 > %arrayidx74597 = getelementptr [8 x <2 x float>]* %a, i32 0, > i32 1, i32 0 ; <float*> [#uses=2] > %tmp76 = load float* %arrayidx74597,

On Aug 19, 2008, at 13:36, kirill havok wrote: > I got very interested in LLVM project, and I decided to start > writing my own scripting language based on it. By studying the > documentation, I could not find how to call external function, > written in C. That is, I have a set of functions written in C/C++, I > generate code, using LLVM C++ interface, how can I call(or

Hello, I got very interested in LLVM project, and I decided to start writing my own scripting language based on it. By studying the documentation, I could not find how to call external function, written in C. That is, I have a set of functions written in C/C++, I generate code, using LLVM C++ interface, how can I call(or register in machine in run-time) my external functions? Maybe I just missed

Hi, I ran into a case where ScalarReplAggregates can not promote an array of vectors into registers, e..g, %a = alloca [8 x <2 x float>], align 8 %arrayidx74597 = getelementptr [8 x <2 x float>]* %a, i32 0, i32 1, i32 0 ; <float*> [#uses=2] %tmp76 = load float* %arrayidx74597, align 8 %arrayidx74598 = getelementptr [8 x <2 x float>]* %a, i32 0,

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, vector and FP values, as if the value was stored to memory with one...

...ect:* Re: [llvm-dev] [GlobalISel] A Proposal for global instruction > selection > > > > 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, vector and FP...

....com>); llvm-dev > > Subject: Re: [llvm-dev] [GlobalISel] A Proposal for global instruction selection > > 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, vector and FP values, as if the value wa...

...[GlobalISel] A Proposal for global instruction selection >> >> >> 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...

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