search for: simpleti

I'm trying to understand why this assertion is here. LegalizeAction getCondCodeAction(ISD::CondCode CC, EVT VT) const { assert((unsigned)CC < array_lengthof(CondCodeActions) && (unsigned)VT.getSimpleVT().SimpleTy < sizeof(CondCodeActions[0])*4 && "Table isn't big enough!"); LegalizeAction Action = (LegalizeAction)

On Thu, 26 Jul 2012 21:15:35 +0000 "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > Well, I found out the reason why this assert is here, and this is > problematic. > > CondCodeActions only supports up to 32 different value types. Since > we are past 32, what LLVM has is broken. > > Currently the 4 different Legalize states are stored in successive >

Well, I found out the reason why this assert is here, and this is problematic. CondCodeActions only supports up to 32 different value types. Since we are past 32, what LLVM has is broken. Currently the 4 different Legalize states are stored in successive bits and packed into a uin64_t, see TargetLowering.h. /// CondCodeActions - For each condition code (ISD::CondCode) keep a /// LegalizeAction

Yeah just the ordering are the real difference. Also, I use shifts and masks instead of conditionals and modules. My patch is attached. For me either patch is fine, but what LLVM has now is broken. Either patch is fine, just need approval from someone to submit. Micah > -----Original Message----- > From: Hal Finkel [mailto:hfinkel at anl.gov] > Sent: Thursday, July 26, 2012 2:39 PM

I searched the archives and found this from last month: I ran into the same problem and fixed it by forcing the MVT::SimpleValueType enum to be 64 bits so that all of the types in the union later in the class are the same size. I tested this on ppc64 and x86_64. Index: include/llvm/CodeGen/ValueTypes.h =================================================================== ---

I was running into a problem with compiling llvm with gcc 4.4 on fedora 11 with --enable-optimized. I was seeing this warning dozens of times: /net/hakodate/scratch/llvm/llvm/include/llvm/CodeGen/ValueTypes.h: In member function ‘llvm::SDNode*<unnamed>::SPUDAGToDAGISel::Select(llvm::SDValue)’: /net/hakodate/scratch/llvm/llvm/include/llvm/CodeGen/ValueTypes.h:362: warning: comparison always

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

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

I tried adding them in my backend however I run into the assertion assert((unsigned)VT.SimpleTy < sizeof(LoadExtActions[0])*4 && ExtType < array_lengthof(LoadExtActions) && "Table isn't big enough!"); What does the assertion mean ? thanks for all help!! shrey On Wed, Jul 14, 2010 at 6:56 PM, Eli Friedman <eli.friedman at

On Aug 24, 2009, at 1:32 AM, Duncan Sands wrote: > unfortunately, race detectors like helgrind don't like this kind of > thing, and report it as a race. Last time I asked about it I was > told that fixing it would be too hard/expensive. I know, and it's somewhat unfortunate. However, this path is extremely hot in LLC, and was significantly contended using only two threads. I

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

Yes, that works much better. However, I fear the problem is more to do with trying to force enums to be a different size which appears not to be supported by most compilers. The IBM C++ compiler apparently has a #pragma which can be used to do it and gcc 4.3 seems to be happy with the hack described but as Duncan says trying to force this behavior in a union is probably less than desirable in the

On Fri, Jul 16, 2010 at 5:14 PM, shreyas krishnan <shreyas76 at gmail.com> wrote: > I tried adding them in my backend however I run into the assertion > >  assert((unsigned)VT.SimpleTy < sizeof(LoadExtActions[0])*4 && >           ExtType < array_lengthof(LoadExtActions) && >           "Table isn't big enough!"); > > What does the

On Aug 18, 2009, at 11:50 AM, Erick Tryzelaar wrote: > I was running into a problem with compiling llvm with gcc 4.4 on > fedora 11 with --enable-optimized. I was seeing this warning dozens of > times: > > /net/hakodate/scratch/llvm/llvm/include/llvm/CodeGen/ValueTypes.h: In > member function > ‘llvm::SDNode*<unnamed>::SPUDAGToDAGISel::Select(llvm::SDValue)’: >

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

Hi Neale, > Yes, that works much better. However, I fear the problem is more to do with > trying to force enums to be a different size which appears not to be > supported by most compilers. The IBM C++ compiler apparently has a #pragma > which can be used to do it and gcc 4.3 seems to be happy with the hack > described but as Duncan says trying to force this behavior in a union is

Thanks Eli ...I actually did that ..bumped it up by 2 that I had added. Any thing else that I might have done wrong ? I can see a different assert where it clearly depends on LAST_VALUETYPE assert((unsigned)VT.SimpleTy < MVT::LAST_VALUETYPE thanks shrey On Fri, Jul 16, 2010 at 5:20 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Fri, Jul 16, 2010 at 5:14 PM, shreyas

Hrmm.... PromoteVectorOp doesn't seem to follow this at all. http://llvm.org/svn/llvm-project/llvm/trunk/lib/CodeGen/SelectionDAG/LegalizeVectorOps.cpp SDValue VectorLegalizer::PromoteVectorOp(SDValue Op) { // Vector "promotion" is basically just bitcasting and doing the operation // in a different type. For example, x86 promotes ISD::AND on v2i32 to // v1i64. EVT VT =

Make sure you’re running LLVM with assertions enabled. You’ll get more information about what’s going wrong that way. That said, yes, this looks like a bug. Specifically, SelectionDAGLegalize::ExpandConstantFP() assumes that f32 is the smallest floating point constant type it’ll need to handle, and that MVT enum ordering reflects that. while (SVT != MVT::f32) {

Here there is the dump: SelectionDAG.cpp:81: static bool llvm::ConstantFPSDNode::isValueValidForType(llvm::EVT, const llvm::APFloat &): Assertion `VT.isFloatingPoint() && "Can only convert between FP types"' failed. 0 libLLVMSupport.so 0x00007f7405022de5 llvm::sys::PrintStackTrace(_IO_FILE*) + 37 1 libLLVMSupport.so 0x00007f74050232e3 2 libpthread.so.0