similar to: [LLVMdev] Matching addsub

Displaying 20 results from an estimated 1000 matches similar to: "[LLVMdev] Matching addsub"

2011 Oct 18
0
[LLVMdev] Matching addsub
Hi Hal, you should probably add a target specific DAG combine that synthesizes the appropriate target instruction. This is how I handled x86 horizontal add (see the FHADD X86 opcode). If it turns out that the same thing is useful for other targets then it can be generalized later. Ciao, Duncan. On 10/18/11 00:40, Hal Finkel wrote: > How should I go about matching floating-point addsub-like
2011 Oct 18
1
[LLVMdev] Matching addsub
On Tue, 2011-10-18 at 10:51 -0700, Dan Gohman wrote: > On Oct 17, 2011, at 6:40 PM, Hal Finkel wrote: > > > On Mon, 2011-10-17 at 17:33 -0700, Dan Gohman wrote: > >> On Oct 17, 2011, at 3:40 PM, Hal Finkel wrote: > >> > >>> How should I go about matching floating-point addsub-like vector > >>> instructions? My first inclination is to write
2011 Oct 18
0
[LLVMdev] Matching addsub
On Oct 17, 2011, at 3:40 PM, Hal Finkel wrote: > How should I go about matching floating-point addsub-like vector > instructions? My first inclination is to write something which matches > build_vector 1.0, -1.0, and then use that in combination with a match on > fadd, but that does not seem to work. I think this is because > BUILD_VECTOR cannot ever be "Legal", and so it
2011 Oct 18
2
[LLVMdev] Matching addsub
On Mon, 2011-10-17 at 17:33 -0700, Dan Gohman wrote: > On Oct 17, 2011, at 3:40 PM, Hal Finkel wrote: > > > How should I go about matching floating-point addsub-like vector > > instructions? My first inclination is to write something which matches > > build_vector 1.0, -1.0, and then use that in combination with a match on > > fadd, but that does not seem to work. I
2011 Oct 18
0
[LLVMdev] Matching addsub
On Oct 17, 2011, at 6:40 PM, Hal Finkel wrote: > On Mon, 2011-10-17 at 17:33 -0700, Dan Gohman wrote: >> On Oct 17, 2011, at 3:40 PM, Hal Finkel wrote: >> >>> How should I go about matching floating-point addsub-like vector >>> instructions? My first inclination is to write something which matches >>> build_vector 1.0, -1.0, and then use that in
2008 Oct 26
0
[LLVMdev] Turning on LegalizeTypes by default
On Oct 26, 2008, at 1:03 AM, Duncan Sands wrote: > Hi all, I plan to turn on the new type legalization infrastructure > "LegalizeTypes" by default tomorrow. This is a redesign/ > reimplementation > of the logic currently in LegalizeDAG that turns (for example) 64 bit > arithmetic on a 32 bit machine into a series of 32 bit operations. > As well > as being a
2011 Dec 16
2
[LLVMdev] Vector immediates in tablegen w/o build_vector?
I have two patterns in tablegen that do look like the exact same thing: Pat 1) def MOV_v4i16 : ILFormat<IL_OP_MOV, (outs GPRV4I16:$dst), (ins i16imm:$val), asm, [(set GPRV4I16:$dst, (build_vector (i16 imm:$val)))]>; Pat 2) def v4i16imm : Operand<v4i16>; def MOV_v4i16 : ILFormat<IL_OP_MOV, (outs GPRV4I16:$dst), (ins v4i16imm:$val), asm, [(set
2009 Feb 02
4
[LLVMdev] type legalizer promoting BUILD_VECTORs
LLVM's type legalizer is changing the types of BUILD_VECTORs in a way that seems wrong to me, but I'm not sure if this is a bug or if some targets may be relying on it. On a 32-bit target, the default action for legalizing i8 and i16 types is to promote them. If you then have a BUILD_VECTOR to construct a legal vector type composed of i8 or i16 values, the type legalizer will
2008 Oct 26
6
[LLVMdev] Turning on LegalizeTypes by default
Hi all, I plan to turn on the new type legalization infrastructure "LegalizeTypes" by default tomorrow. This is a redesign/reimplementation of the logic currently in LegalizeDAG that turns (for example) 64 bit arithmetic on a 32 bit machine into a series of 32 bit operations. As well as being a cleaner design, it also supports code generation for arbitrary precision integers such as
2009 Feb 02
0
[LLVMdev] type legalizer promoting BUILD_VECTORs
On Mon, Feb 2, 2009 at 11:31 AM, Bob Wilson <bob.wilson at apple.com> wrote: > LLVM's type legalizer is changing the types of BUILD_VECTORs in a way > that seems wrong to me, but I'm not sure if this is a bug or if some > targets may be relying on it. > > On a 32-bit target, the default action for legalizing i8 and i16 types > is to promote them. This isn't
2009 Nov 10
0
[LLVMdev] Altivec vs the type legalizer
On Nov 9, 2009, at 6:11 PM, Dale Johannesen wrote: > PPC Altivec supports vector type v16i8 (and others) where the element > type is not legal (in llvm's implementation). When we have a > BUILD_VECTOR of these types with constant elements, LegalizeTypes > first promotes the element types to i32, then builds a constant pool > entry of type v16i32. This is wrong. I can
2009 Feb 02
0
[LLVMdev] type legalizer promoting BUILD_VECTORs
Hi Bob, > LLVM's type legalizer is changing the types of BUILD_VECTORs in a way > that seems wrong to me, but I'm not sure if this is a bug or if some > targets may be relying on it. > > On a 32-bit target, the default action for legalizing i8 and i16 types > is to promote them. If you then have a BUILD_VECTOR to construct a > legal vector type composed of
2009 Nov 10
4
[LLVMdev] Altivec vs the type legalizer
PPC Altivec supports vector type v16i8 (and others) where the element type is not legal (in llvm's implementation). When we have a BUILD_VECTOR of these types with constant elements, LegalizeTypes first promotes the element types to i32, then builds a constant pool entry of type v16i32. This is wrong. I can fix it by truncating the elements back to i8 in ExpandBUILD_VECTOR. Does
2009 Nov 10
1
[LLVMdev] Altivec vs the type legalizer
Hi Dale, I think Bob is right: the type legalizer shouldn't be turning v16i8 into v16i32, what should happen is that the return type of the BUILD_VECTOR continues to be v16i8, but the type of the operands changes to i32, so you end up with a BUILD_VECTOR that takes 16 lots of i32, and produces a v16i8. The target then has all the info it needs to produce the best code, but needs to be careful
2009 May 21
0
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
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
2009 May 20
2
[LLVMdev] [PATCH] Add new phase to legalization to handle vector operations
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
2009 Feb 02
1
[LLVMdev] type legalizer promoting BUILD_VECTORs
On Feb 2, 2009, at 1:51 PM, Eli Friedman wrote: > On Mon, Feb 2, 2009 at 11:31 AM, Bob Wilson <bob.wilson at apple.com> > wrote: >> LLVM's type legalizer is changing the types of BUILD_VECTORs in a way >> that seems wrong to me, but I'm not sure if this is a bug or if some >> targets may be relying on it. >> >> On a 32-bit target, the default
2009 Feb 03
1
[LLVMdev] type legalizer promoting BUILD_VECTORs
On Feb 2, 2009, at 1:22 PM, Duncan Sands wrote: > another way this could be done is to say that the operands of a > BUILD_VECTOR don't have to have the same type as the element type > of the built vector. Then when the type legalizer sees a > v4i16 = BUILD_VECTOR(i16, i16, i16, i16) it can turn this into a > v4i16 = BUILD_VECTOR(i32, i32, i32, i32) and it will be happy >
2009 Feb 23
0
[LLVMdev] [llvm-commits] [llvm] r65296 - in /llvm/trunk: include/llvm/CodeGen/ lib/CodeGen/SelectionDAG/ lib/Target/CellSPU/ lib/Target/PowerPC/ lib/Target/X86/ test/CodeGen/X86/
On Feb 23, 2009, at 2:15 PM, Scott Michel wrote: > And the first thing the helper method would have to check is if this > SDNode is a BUILD_VECTOR node, right? Right. It's really not much different than what you have now, just moving the point where you check. In your code right now, when you want to call your isConstantSplat method, you first dyn_cast the node to a
2009 Feb 23
2
[LLVMdev] [llvm-commits] [llvm] r65296 - in /llvm/trunk: include/llvm/CodeGen/ lib/CodeGen/SelectionDAG/ lib/Target/CellSPU/ lib/Target/PowerPC/ lib/Target/X86/ test/CodeGen/X86/
On Mon, Feb 23, 2009 at 1:46 PM, Chris Lattner <clattner at apple.com> wrote: > > On Feb 23, 2009, at 1:20 PM, Scott Michel wrote: > > Chris: >> >> I did float this by the dev list first a couple of weeks ago, didn't >> receive any comments. >> > > Ok, I didn't see it, sorry about that. It happens. :-) > a) Convenience for the