search for: llvmty

...)) return DAG.getSetCC(N->getDebugLoc(), VT, N0.getOperand(0), N0.getOperand(1), cast<CondCodeSDNode>(N0.getOperand(2))->get()); SVT.getSizeInBits() crashes, because TLI.getSetCCResultType returns an invalid MVT type and LLVMTy is NULL. Since there is no way to specify the LLVMTy manually, there is no way to fix this without finding all of the locations that use this and disabling them. I'm disabling via VT.isPow2VectorType() because an extra check, but it seems like this isn't preferable. So should I conditiona...

Hi Micah, I think that getSetCCResultType should only be called for legal types. Disabling it on isPow2VectorType is not the way to go because there are other illegal vector types which are pow-of-two. I suggest that you call it only after type-legalization. BTW, you can't set the LLVMTy yourself because you don't have access to the LLVMContext at that point. Nadav From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Villmow, Micah Sent: Friday, July 27, 2012 21:52 To: Developers Mailing List Subject: [LLVMdev] TLI.getSetCCResultType() an...

...by design? Hi Micah, I think that getSetCCResultType should only be called for legal types. Disabling it on isPow2VectorType is not the way to go because there are other illegal vector types which are pow-of-two. I suggest that you call it only after type-legalization. BTW, you can't set the LLVMTy yourself because you don't have access to the LLVMContext at that point. Nadav From: llvmdev-bounces at cs.uiuc.edu<mailto:llvmdev-bounces at cs.uiuc.edu> [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Villmow, Micah Sent: Friday, July 27, 2012 21:52 To: Developers Mailing List S...

...by design? Hi Micah, I think that getSetCCResultType should only be called for legal types. Disabling it on isPow2VectorType is not the way to go because there are other illegal vector types which are pow-of-two. I suggest that you call it only after type-legalization. BTW, you can't set the LLVMTy yourself because you don't have access to the LLVMContext at that point. Nadav From: llvmdev-bounces at cs.uiuc.edu<mailto:llvmdev-bounces at cs.uiuc.edu> [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Villmow, Micah Sent: Friday, July 27, 2012 21:52 To: Developers Mailing List S...

...d' The problem appears to be gcc 4.4 optimizing away comparisons of one plus the last item in the SimpleValueType enum, like this: bool operator==(const EVT VT) const { if (V.SimpleTy == VT.V.SimpleTy) { if (V.SimpleTy == MVT::LastSimpleValueType+1) return LLVMTy == VT.LLVMTy; return true; } return false; } I confirmed this by adding a dummy value to the enum that equals LastSimpleValueType+1, and both the warning and the failures in "make check" go away. Is this the right thing to do, or is there a better way to d...

...FIRST_INTEGER_VALUETYPE $10 = true (gdb) p llvm::MVT::i8 <= LAST_INTEGER_VALUETYPE $11 = true So the SimpleTy variable which is a SimpleTypeValue is behaving strangely. It's found within a private definition: union { uintptr_t V; SimpleValueType SimpleTy; const Type *LLVMTy; }; The comment in the above fix indicates that in this 64-bit system the enum needs to be 64-bits is correct, but the fix doesn't seem to do it. Neale On 4/7/09 12:36 PM, "Duncan Sands" <baldrick at free.fr> wrote: > Hi, > >> llvm[1]: Building Intrinsics.g...

* Neale Ferguson: > So the SimpleTy variable which is a SimpleTypeValue is behaving strangely. > It's found within a private definition: > > union { > uintptr_t V; > SimpleValueType SimpleTy; > const Type *LLVMTy; > }; > > The comment in the above fix indicates that in this 64-bit system the enum > needs to be 64-bits is correct, but the fix doesn't seem to do it. What's the union being used for? I wouldn't be surprised if this is pushing into undefined territory.

...ars to be gcc 4.4 optimizing away comparisons of one > plus the last item in the SimpleValueType enum, like this: > > bool operator==(const EVT VT) const { > if (V.SimpleTy == VT.V.SimpleTy) { > if (V.SimpleTy == MVT::LastSimpleValueType+1) > return LLVMTy == VT.LLVMTy; > return true; > } > return false; > } ValueTypes.h was particularly heavily impacted by the recent API changes, and it looks like it's a bit disheveled at the moment. > > I confirmed this by adding a dummy value to the enum that equ...

...union is probably less than desirable in the long term. Another ugly hack that I tried: union { uintptr_t V; #ifdef _LP64 SimpleValueType SimpleTyU[2]; # define SimpleTy SimpleTyU[1] #else SimpleValueType SimpleTyU[1]; # define SimpleTy SimpleTyU[0] #endif const Type *LLVMTy; }; This works on my big endian 64-bit system but I've not seen what damage it may do on other platform types. On 4/7/09 4:09 PM, "Anton Korobeynikov" <anton at korobeynikov.info> wrote: > Hello, > >> +static const uintptr_t minus_one = -1; > -1 here is o...

...33ae34 in kill$UNIX2003 () #2 0x933ad23a in raise () #3 0x933b9679 in abort () #4 0x933ae3db in __assert_rtn () #5 0x0008bd8f in llvm::MVT::getVectorElementType (this=0xbfffdda4) at ValueTypes.h:317 #6 0x002aed06 in BuildSplatI (Val=0, SplatSize=8, VT={{V = 24, SimpleTy = llvm::MVT::v4i32, LLVMTy = 0x18}}, DAG=@0x16088a0, dl={Idx = 4294967295}) at PPCISelLowering.cpp:311\ 5 #7 0x002afae4 in llvm::PPCTargetLowering::LowerBUILD_VECTOR (this=0x1803d58, Op={Node = 0x157a530, ResNo = 0}, DAG=@0x16088a0) at PPCISelLowering.cpp:3200 #8 0x002bb54f in llvm::PPCTargetLowering::LowerOperation...

...0x933ad23a in raise () > #3 0x933b9679 in abort () > #4 0x933ae3db in __assert_rtn () > #5 0x0008bd8f in llvm::MVT::getVectorElementType (this=0xbfffdda4) > at ValueTypes.h:317 > #6 0x002aed06 in BuildSplatI (Val=0, SplatSize=8, VT={{V = 24, > SimpleTy = llvm::MVT::v4i32, LLVMTy = 0x18}}, DAG=@0x16088a0, > dl={Idx = 4294967295}) at PPCISelLowering.cpp:311\ > 5 > #7 0x002afae4 in llvm::PPCTargetLowering::LowerBUILD_VECTOR > (this=0x1803d58, Op={Node = 0x157a530, ResNo = 0}, DAG=@0x16088a0) > at PPCISelLowering.cpp:3200 > #8 0x002bb54f in llvm::PPCT...

...() >> #3 0x933b9679 in abort () >> #4 0x933ae3db in __assert_rtn () >> #5 0x0008bd8f in llvm::MVT::getVectorElementType (this=0xbfffdda4) at >> ValueTypes.h:317 >> #6 0x002aed06 in BuildSplatI (Val=0, SplatSize=8, VT={{V = 24, SimpleTy = >> llvm::MVT::v4i32, LLVMTy = 0x18}}, DAG=@0x16088a0, dl={Idx = 4294967295}) at >> PPCISelLowering.cpp:311\ >> 5 >> #7 0x002afae4 in llvm::PPCTargetLowering::LowerBUILD_VECTOR >> (this=0x1803d58, Op={Node = 0x157a530, ResNo = 0}, DAG=@0x16088a0) at >> PPCISelLowering.cpp:3200 >> #8 0x002b...

...#2 0x933ad23a in raise () > #3 0x933b9679 in abort () > #4 0x933ae3db in __assert_rtn () > #5 0x0008bd8f in llvm::MVT::getVectorElementType (this=0xbfffdda4) at > ValueTypes.h:317 > #6 0x002aed06 in BuildSplatI (Val=0, SplatSize=8, VT={{V = 24, SimpleTy = > llvm::MVT::v4i32, LLVMTy = 0x18}}, DAG=@0x16088a0, dl={Idx = 4294967295}) at > PPCISelLowering.cpp:311\ > 5 > #7 0x002afae4 in llvm::PPCTargetLowering::LowerBUILD_VECTOR > (this=0x1803d58, Op={Node = 0x157a530, ResNo = 0}, DAG=@0x16088a0) at > PPCISelLowering.cpp:3200 > #8 0x002bb54f in llvm::PPCTargetL...

Hello, > +static const uintptr_t minus_one = -1; -1 here is of signed int type. What if you will use -1ULL ? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

...t; Another ugly hack that I tried: > > union { > uintptr_t V; > #ifdef _LP64 > SimpleValueType SimpleTyU[2]; > # define SimpleTy SimpleTyU[1] > #else > SimpleValueType SimpleTyU[1]; > # define SimpleTy SimpleTyU[0] > #endif > const Type *LLVMTy; > }; > > This works on my big endian 64-bit system but I've not seen what damage it > may do on other platform types. > > > On 4/7/09 4:09 PM, "Anton Korobeynikov" <anton at korobeynikov.info> wrote: > > > Hello, > > > >> +s...

...fore type legalization. What I'm looking for is the ability to create a new Type * in getSetCCResult(), which requires an LLVM Context, which is simply not available to the method as near as I can tell… The incoming EVT doesn't seem to have a path to it's context that I can access (EVT.LLVMTy is 'private'). Suggestions? Thanks, Richard

...>> #3 0x933b9679 in abort () >> #4 0x933ae3db in __assert_rtn () >> #5 0x0008bd8f in llvm::MVT::getVectorElementType (this=0xbfffdda4) >> at ValueTypes.h:317 >> #6 0x002aed06 in BuildSplatI (Val=0, SplatSize=8, VT={{V = 24, >> SimpleTy = llvm::MVT::v4i32, LLVMTy = 0x18}}, DAG=@0x16088a0, >> dl={Idx = 4294967295}) at PPCISelLowering.cpp:311\ >> 5 >> #7 0x002afae4 in llvm::PPCTargetLowering::LowerBUILD_VECTOR >> (this=0x1803d58, Op={Node = 0x157a530, ResNo = 0}, DAG=@0x16088a0) >> at PPCISelLowering.cpp:3200 >> #8...

Hi, > llvm[1]: Building Intrinsics.gen.tmp from Intrinsics.td > tblgen: IntrinsicEmitter.cpp:163: void EmitTypeForValueType(std::ostream&, > llvm::MVT::SimpleValueType): Assertion `false && "Unsupported ValueType!"' > failed. this came up before IIRC, but I don't remember the details - buggy system compiler? Try searching the archives. Also, if you

Hi, I am beginning the porting process for Linux on System z (aka IBM Mainframe). I thought I¹d build LLVM first with the c and cpp backends so that tools like TableGen would be created that I¹d then use to process the .td files that I¹ll be creating. So I used svn to grab the code from the repository and ran configure and make. However, the build breaks at this point: llvm[1]: Building

Duncan: I'm still stymied how this whole thread ended up about shuffle vector nodes, when the original problem was my build vector patch. I'm still working on backing the build vector patch out (it isn't clean with all of the intervening commits and I have pressing management tasks which command my attention.) -scooter On Tue, Feb 24, 2009 at 12:28 AM, Duncan Sands <baldrick at