search for: getsimplevt

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) ((CondCodeActions[CC] >> (2*VT.getSimpleVT().SimpleTy)) & 3); assert(Action != Promote && "Can't promote con...

...y >> 5] |= (uint64_t)Action > << (VT.SimpleTy - 32)*2; } > > getCondCodeAction then becomes: > LegalizeAction > getCondCodeAction(ISD::CondCode CC, EVT VT) const { > assert((unsigned)CC < array_lengthof(CondCodeActions) && > (unsigned)VT.getSimpleVT().SimpleTy < > MVT::LAST_VECTOR_VALUETYPE && "Table isn't big enough!"); > LegalizeAction Action = (LegalizeAction) > ((CondCodeActions[CC][VT.getSimpleVT().SimpleTy >> 5] >> > (2*(VT.getSimpleVT().SimpleTy - 32))) & 3); assert(Action !...

...eActions[(unsigned)CC][VT.SimpleTy >> 5] |= (uint64_t)Action << (VT.SimpleTy - 32)*2; } getCondCodeAction then becomes: LegalizeAction getCondCodeAction(ISD::CondCode CC, EVT VT) const { assert((unsigned)CC < array_lengthof(CondCodeActions) && (unsigned)VT.getSimpleVT().SimpleTy < MVT::LAST_VECTOR_VALUETYPE && "Table isn't big enough!"); LegalizeAction Action = (LegalizeAction) ((CondCodeActions[CC][VT.getSimpleVT().SimpleTy >> 5] >> (2*(VT.getSimpleVT().SimpleTy - 32))) & 3); assert(Action != Pro...

...<< > > (VT.SimpleTy - 32)*2; } > > > > getCondCodeAction then becomes: > > LegalizeAction > > getCondCodeAction(ISD::CondCode CC, EVT VT) const { > > assert((unsigned)CC < array_lengthof(CondCodeActions) && > > (unsigned)VT.getSimpleVT().SimpleTy < > > MVT::LAST_VECTOR_VALUETYPE && "Table isn't big enough!"); > > LegalizeAction Action = (LegalizeAction) > > ((CondCodeActions[CC][VT.getSimpleVT().SimpleTy >> 5] >> > > (2*(VT.getSimpleVT().SimpleTy - 32))) &...

...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 don't have a non-contended solution offhand. >> VTs[VT.getSimpleVT().SimpleTy] = VT; >> - return &VTs[VT.getSimpleVT().SimpleTy]; >> + sys::MemoryFence(); > > I don't think this fence actually does anything useful unless > users of the pointer do a fence before reading the contents > of the pointer. That said, I think alpha i...

...if (VT.isInteger()) // First promote to a power-of-two size, then expand if necessary. return VT == VT.getRoundIntegerType() ? Expand : Promote; assert(0 && "Unsupported extended type!"); return Legal; } unsigned I = VT.getSimpleVT(); assert(I<4*array_lengthof(ValueTypeActions)*sizeof(ValueTypeActions[0])) ; return (LegalizeAction)((ValueTypeActions[I>>4] >> ((2*I) & 31)) & 3); } void setTypeAction(MVT VT, LegalizeAction Action) { unsigned I = VT.getSimpleVT(); assert(I<4*ar...

Dan Gohman wrote: > There certainly are wishlist items for TableGen and TableGen-based > instruction descriptions, though I don't know of an official list. > Offhand, > a few things that come to mind are the ability to handle nodes with > multiple results, Is there an official workaround, BTW? - Volodya

Is there a way to force llvm to promote all smaller types to i32 instead of i16? Thanks, Micah Villmow Systems Engineer Advanced Technology & Performance Advanced Micro Devices Inc. S1-609 One AMD Place Sunnyvale, CA. 94085 P: 408-749-3966 -------------- next part -------------- An HTML attachment was scrubbed... URL:

...ToPromoteTo(ISD::AND, MVT::v4i8) is MVT::v2i32; The reason why this occurs is: // See if this has an explicit type specified. std::map<std::pair<unsigned, MVT::SimpleValueType>, MVT::SimpleValueType>::const_iterator PTTI = PromoteToType.find(std::make_pair(Op, VT.getSimpleVT().SimpleTy)); if (PTTI != PromoteToType.end()) return PTTI->second; assert((VT.isInteger() || VT.isFloatingPoint()) && "Cannot autopromote this type, add it with AddPromotedToType."); EVT NVT = VT; do { NVT = (MVT::SimpleValueType)(NVT.getSimp...

...f ‘llvm::ISD’ Renamed to DBG_STOPPOINT. 8) error: ‘class llvm::SDValue’ has no member named ‘Val’ SDOperand had 'Val' which can be replaced by getNode(). 9) switch(op.getOperand(1).getValueType()) does not work In our case I could replace it with switch(op.getOperand(1).getValueType().getSimpleVT()) 10) SelectionDAGIsel::InstructionSelectBasicBlock removed Replaced with InstructionSelect() 11) no matching function for call to llvm::AsmPrinter::AsmPrinter(std::basic_ostream<char, std::char_traits<char>... The stream argument has been changed to llvm::raw_ostream Als...

...pecifically, 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) { SVT = (MVT::SimpleValueType)(SVT.getSimpleVT().SimpleTy - 1); ... } That function, and possibly others, need to be taught how to handle half-floats, it looks like. -Jim On Jun 17, 2013, at 6:59 AM, Alessio Giovanni Baroni <alessiogiovanni.baroni at gmail.com> wrote: > Hi, > > if I write the following simple program:...

In the 2.3 release, we included a list of the major LLVM API changes. If you are working on upgrading your code from 2.3 to 2.4, I'd appreciate it if you could compile a list of the major stumbling blocks you have, so that others can benefit from your experience. Please send any info to the list, thanks! -Chris

...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) { > > SVT = (MVT::SimpleValueType)(SVT.getSimpleVT().SimpleTy - 1); > ... > } > > That function, and possibly others, need to be taught how to handle > half-floats, it looks like. > > -Jim > > On Jun 17, 2013, at 6:59 AM, Alessio Giovanni Baroni < > alessiogiovanni.baroni at gmail.com> wrote: > > Hi,...

Hi, if I write the following simple program: target datalayout = "e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" define void @foo () { %1 = alloca half store half 0xH42CC, half* %1 ; 0xH42CC = 3.4 %2 = load half* %1

...ToPromoteTo(ISD::AND, MVT::v4i8) is MVT::v2i32; The reason why this occurs is: // See if this has an explicit type specified. std::map<std::pair<unsigned, MVT::SimpleValueType>, MVT::SimpleValueType>::const_iterator PTTI = PromoteToType.find(std::make_pair(Op, VT.getSimpleVT().SimpleTy)); if (PTTI != PromoteToType.end()) return PTTI->second; assert((VT.isInteger() || VT.isFloatingPoint()) && "Cannot autopromote this type, add it with AddPromotedToType."); EVT NVT = VT; do { NVT = (MVT::SimpleValueType)(NVT.getSimp...

...ores. For example, on x86-32 an f64 can be stored in one // processor operation but an i64 (which is not legal) requires two. So the // transform should not be done in this case. if (Value.getOpcode() != ISD::TargetConstantFP) { SDValue Tmp; switch (CFP->getValueType(0).getSimpleVT().SimpleTy) { default: llvm_unreachable("Unknown FP type"); case MVT::f80: // We don't do this for these yet. case MVT::f128: case MVT::ppcf128: break; case MVT::f32: if ((isTypeLegal(MVT::i32) && !LegalOperations && !ST...

...MVT::v2i32; > > The reason why this occurs is: > // See if this has an explicit type specified. > std::map<std::pair<unsigned, MVT::SimpleValueType>, > MVT::SimpleValueType>::const_iterator PTTI = > PromoteToType.find(std::make_pair(Op, > VT.getSimpleVT().SimpleTy)); > if (PTTI != PromoteToType.end()) return PTTI->second; > > assert((VT.isInteger() || VT.isFloatingPoint()) && > "Cannot autopromote this type, add it with > AddPromotedToType."); > > EVT NVT = VT; > do { >...

...MVT::v2i32; > > The reason why this occurs is: > // See if this has an explicit type specified. > std::map<std::pair<unsigned, MVT::SimpleValueType>, > MVT::SimpleValueType>::const_iterator PTTI = > PromoteToType.find(std::make_pair(Op, > VT.getSimpleVT().SimpleTy)); > if (PTTI != PromoteToType.end()) return PTTI->second; > > assert((VT.isInteger() || VT.isFloatingPoint()) && > "Cannot autopromote this type, add it with > AddPromotedToType."); > > EVT NVT = VT; > do { >...

I don't know how your target architecture looks like, but I suspect that <4 x i8> should not be legalized to <1 x i32>. I think that what you are seeing is that <4 x i8> is first split into <2 x i8>, and later promoted to <2 x i32>. At the moment different targets can only affect type-legalization by declaring different legal types. A number of us discussed the

...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) { >> >> SVT = (MVT::SimpleValueType)(SVT.getSimpleVT().SimpleTy - 1); >> ... >> } >> >> That function, and possibly others, need to be taught how to handle >> half-floats, it looks like. >> >> -Jim >> >> On Jun 17, 2013, at 6:59 AM, Alessio Giovanni Baroni < >> alessiogiovanni.baron...