search for: v3i32

...as is into %xmm0 like in the case of vector of four?: retFour: # @retFour .Leh_func_begin1: # BB#0: movaps .LCPI1_0, %xmm0 ret This would of course leave the responsibility of ignoring the 4th lane to the caller. Debugging the code generation, I notice that the v3i32 is widened to v4i32, but when X86TargetLowering::CanLowerReturn, the v3i32 is seems to be split up into three MVT::i32s. If trying with a function that returns a vector of 2 or 4, CanLowerReturn-function gets a MVT::v2i32 or MVT::v4i32, respectively and return by pointer is not used. Where is...

...pes as the log2 > of the > length, biased by one. Using only 6 bits gets us vector lengths up to > (2**64)-2, which Ought To Be Enough For Anyone. Yerk! This would throw a serious wrench in supporting non power of two vector lengths, which is needed by us. We needed to add v3f32 and v3i32 ValueTypes just to define our register file in the .td. -- Christopher Lamb -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070622/f3ce0d40/attachment.html>

James, Thanks for your response. I'm working in LLVM 2.7 (I know, it's old) and the default behavior is already promote. This means that for example a call to DAGTypeLegalizer::getTypeAction(v3i32) in my case and I presume in ARM NEON returns TypeWidenVector. From here legalization calls WidenVectorOperand() to process the STORE node and follows the call chain I have on my original email to FindMemType(). If my analysis is correct then your v316 STOREs are being broken into multiple ones de...

After doing a bunch of work for moving pre-legalize extended ValueTypes into a table in SelectionDAG, I may have just found a simpler approach. There are under 32 simple ValueType values, so we only really need 5 bits to represent those. ValueType is already a 32-bit type on most hosts; what if we make use of the remaining 27 bits instead of using an external table? If we can assume that vector

..., 2012 11:35 AM To: James Molloy; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Expand vector type James, Thanks for your response. I'm working in LLVM 2.7 (I know, it's old) and the default behavior is already promote. This means that for example a call to DAGTypeLegalizer::getTypeAction(v3i32) in my case and I presume in ARM NEON returns TypeWidenVector. From here legalization calls WidenVectorOperand() to process the STORE node and follows the call chain I have on my original email to FindMemType(). If my analysis is correct then your v316 STOREs are being broken into multiple ones de...

...olloy; llvmdev at cs.uiuc.edu > *Subject:* Re: [LLVMdev] Expand vector type > > James, > > Thanks for your response. I’m working in LLVM 2.7 (I know, it’s old) and the > default behavior is already promote. This means that for example a call to > DAGTypeLegalizer::getTypeAction(v3i32) in my case and I presume in ARM NEON > returns TypeWidenVector. From here legalization calls WidenVectorOperand() to > process the STORE node and follows the call chain I have on my original email to > FindMemType(). > > If my analysis is correct then your v316 STOREs are being brok...

Hi, * Is there a way to setup LLVM to automatically convert vec3s to vec4s? Yes, if you specify v3i16 and friends as "promote" instead of "legal", llvm will promote it to a v4i16. The ARM NEON backend does this already. I'm surprised you haven't got this happening already as you mention that LLVM widens your loads to 4-element vectors. (this should happen during

Hello, My input language has support for 3 and 4 element vectors but my target only has support for the latter. The language defines vec3 with the same storage space as vec4 so from a backend perspective they are both the same. I'd really like if I could have LLVM treat vec3 as vec4 but I haven't found out how. Currently the target has emulated support for vec3 through LLVM. Loads are

On Wed, May 20, 2009 at 4:55 PM, Dan Gohman <gohman at apple.com> wrote: > Can you explain why you chose the approach of using a new pass? > I pictured removing LegalizeDAG's type legalization code would > mostly consist of finding all the places that use TLI.getTypeAction > and just deleting code for handling its Expand and Promote. Are you > anticipating something more

On May 20, 2009, at 1:34 PM, Eli Friedman wrote: > On Wed, May 20, 2009 at 1:19 PM, Eli Friedman > <eli.friedman at gmail.com> wrote: > >> Per subject, this patch adding an additional pass to handle vector >> >> operations; the idea is that this allows removing the code from >> >> LegalizeDAG that handles illegal types, which should be a significant

...ed in for any results that are expanded, and - /// the Lo/Hi values are returned. This applies to integer types and Vector - /// types. - void ExpandOp(SDValue O, SDValue &Lo, SDValue &Hi); - - /// WidenVectorOp - Widen a vector operation to a wider type given by WidenVT - /// (e.g., v3i32 to v4i32). The produced value will have the correct value - /// for the existing elements but no guarantee is made about the new elements - /// at the end of the vector: it may be zero, ones, or garbage. This is useful - /// when we have an instruction operating on an illegal vector type and we...