search for: istypelegal

...e a type, i8, > than can exist in different register classes, and the operations that > are legal on that type depend on the current register class. The reason > this is a problem is that legalization happens before register-class > assignment. Yes, that's correct. > Currently, isTypeLegal does not take an opcode parameter, but maybe > changing it to depend on the type of operation (like getTypeToPromoteTo > does) and the opcode of the node's inputs would help? I will try to see if I can fix isTypeLegal. Thanks for your helpful comments. Sebastian -- Qualcomm Innovation C...

...m wrong, but your fundamental issue is that you have a type, i8, than can exist in different register classes, and the operations that are legal on that type depend on the current register class. The reason this is a problem is that legalization happens before register-class assignment. Currently, isTypeLegal does not take an opcode parameter, but maybe changing it to depend on the type of operation (like getTypeToPromoteTo does) and the opcode of the node's inputs would help? -Hal On Thu, 24 May 2012 16:11:30 -0500 Sebastian Pop <spop at codeaurora.org> wrote: > Hi, > > On Tue,...

...y followed by an > extension". So, the "EXT" part is probably irrelevant here, if that's > what's bugging you ;) Nevermind, grepping around shows this is specifically about ISD::EXTLOAD, in LegalizeLoadOps (LegalizeDAG.cpp). There's some code above, with an "isTypeLegal(SrcVT)" check, that tries to turn an EXTLOAD into LOAD+[SZ]EXT. I'm guessing that on your target, both the EXTLOAD from i8 and the i8 type are illegal? In that case, again, I don't know how one could legalize this. -Ahmed

...xist in different register classes, and the operations that >> are legal on that type depend on the current register class. The reason >> this is a problem is that legalization happens before register-class >> assignment. > > Yes, that's correct. > >> Currently, isTypeLegal does not take an opcode parameter, but maybe >> changing it to depend on the type of operation (like getTypeToPromoteTo >> does) and the opcode of the node's inputs would help? > > I will try to see if I can fix isTypeLegal. > Thanks for your helpful comments. Just an idea...

Hi Craig, protecting the transformation with: if (TLI.isTypeLegal(VT) && TLI.isOperationLegal(ISD::SUB, VT) && TLI.isOperationLegal(ISD::ADD, VT) && TLI.isOperationLegal(ISD::SHL, VT) && TLI.isOperationLegal(ISD::SRA, VT)) { shows the same result. Michael On 22.09.2017 07:19, Craig Topper wrote: >...

On Oct 1, 2007, at 11:33 AM, Alireza.Moshtaghi at microchip.com wrote: > So does that mean that LLVM can't lower automatically to 8-bit values? There is no inherent reason. LLVM should be able to lower to 8-bit values. It's probably a bug somewhere. In TargetLowering.h: bool isTypeLegal(MVT::ValueType VT) const { return !MVT::isExtendedVT(VT) && RegClassForVT[VT] != 0; } Is there a 16-bit register class? > I tried defining 8-bit pointers in the subtarget using "p:8:8:8" > but it > asserts at line 566 of TargetData.cpp in the default case of &...

...-build-O0/Release+Asserts/bin/count 1 > -- > Exit Code: 1 > Command Output (stderr): > -- > llc: /media/dh0/llvm-2.9rc1/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:3149: void llvm::SelectionDAGBuilder::visitTargetIntrinsic(const llvm::CallInst&, unsigned int): Assertion `TLI.isTypeLegal(Op.getValueType()) && "Intrinsic uses a non-legal type?"' failed. > Stack dump: > 0. Program arguments: /media/dh0/llvm-2.9-build-O0/Release+Asserts/bin/llc -mtriple=i386-apple-darwin > 1. Running pass 'Function Pass Manager' on module '<stdin>...

...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->isVolatile()) || TLI.isOperationLegalOrCustom(ISD::STORE, MVT::i32)) { Tmp = DAG.getConstant((uint32_t)CFP->getValueAPF(). bitcastToAPInt().getZExtValue(), MVT::i32); return DAG...

...bit! On Oct 1, 2007, at 11:33 AM, Alireza.Moshtaghi at microchip.com wrote: > So does that mean that LLVM can't lower automatically to 8-bit values? There is no inherent reason. LLVM should be able to lower to 8-bit values. It's probably a bug somewhere. In TargetLowering.h: bool isTypeLegal(MVT::ValueType VT) const { return !MVT::isExtendedVT(VT) && RegClassForVT[VT] != 0; } Is there a 16-bit register class? > I tried defining 8-bit pointers in the subtarget using "p:8:8:8" > but it > asserts at line 566 of TargetData.cpp in the default case of &...

Is VT a legal type on Hexagon? It looks like Hexagon may be setting SHL as Custom for every defined vector type. Try adding TLI.isTypeLegal(VT) too. ~Craig On Thu, Sep 21, 2017 at 10:06 PM, Haidl, Michael < michael.haidl at uni-muenster.de> wrote: > Hi Sanjay, > > thanks for this information. I did get a little bit further with the > patch. However, Hexagon gives me headaches. > > I tried to limit the scope o...

...widened, for example <3 x float> -> <4 x float>. + // widened, for example <3 x i8> -> <4 x i8>. if (!VT.isPow2VectorType()) { NumElts = (unsigned)NextPowerOf2(NumElts); EVT NVT = EVT::getVectorVT(Context, EltVT, NumElts); + while (!isTypeLegal(NVT)) { + NumElts = (unsigned)NextPowerOf2(NumElts); + NVT = EVT::getVectorVT(Context, EltVT, NumElts); + } return LegalizeKind(TypeWidenVector, NVT); } From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Nadav Rotem S...

So does that mean that LLVM can't lower automatically to 8-bit values? I tried defining 8-bit pointers in the subtarget using "p:8:8:8" but it asserts at line 566 of TargetData.cpp in the default case of TargetData::getIntPtrType() Is it difficult to add 8-bit support? A. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On

...eqd | /media/dh0/llvm-2.9-build-O0/Release+Asserts/bin/count 1 -- Exit Code: 1 Command Output (stderr): -- llc: /media/dh0/llvm-2.9rc1/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:3149: void llvm::SelectionDAGBuilder::visitTargetIntrinsic(const llvm::CallInst&, unsigned int): Assertion `TLI.isTypeLegal(Op.getValueType()) && "Intrinsic uses a non-legal type?"' failed. Stack dump: 0. Program arguments: /media/dh0/llvm-2.9-build-O0/Release+Asserts/bin/llc -mtriple=i386-apple-darwin 1. Running pass 'Function Pass Manager' on module '<stdin>'. 2. Ru...

Hello Xerxes, > llvm 2.9rc1 test on Dualcore ARM running Ubuntu Natty What is the gcc used for the compilation? Can you try to do the -O0 build and see whether this changed the stuff? -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

...aghi at microchip.com wrote: > >> So does that mean that LLVM can't lower automatically to 8-bit >> values? > > There is no inherent reason. LLVM should be able to lower to 8-bit > values. It's probably a bug somewhere. > > In TargetLowering.h: > > bool isTypeLegal(MVT::ValueType VT) const { > return !MVT::isExtendedVT(VT) && RegClassForVT[VT] != 0; > } > > Is there a 16-bit register class? > >> I tried defining 8-bit pointers in the subtarget using "p:8:8:8" >> but it >> asserts at line 566 of Target...

...aghi at microchip.com wrote: > >> So does that mean that LLVM can't lower automatically to 8-bit >> values? > > There is no inherent reason. LLVM should be able to lower to 8-bit > values. It's probably a bug somewhere. > > In TargetLowering.h: > > bool isTypeLegal(MVT::ValueType VT) const { > return !MVT::isExtendedVT(VT) && RegClassForVT[VT] != 0; > } > > Is there a 16-bit register class? > >> I tried defining 8-bit pointers in the subtarget using "p:8:8:8" >> but it >> asserts at line 566 of Target...

...election and the type legalizer that it's okay to replace the normal "and" with this truncate call, which leads to your troubles later on. It would seem that the truncate is created by: TargetLowering::SimplifySetCC ... if (N0.getOpcode() == ISD::SETCC && isTypeLegal(VT) && VT.bitsLE(N0.getValueType())) { bool TrueWhenTrue = (Cond == ISD::SETEQ) ^ (N1C->getAPIntValue() != 1); if (TrueWhenTrue) return DAG.getNode(ISD::TRUNCATE, dl, VT, N0); // Invert the condition. ISD::CondCode CC = cast<CondCodeSDN...

...3 x float> -> <4 x float>. > + // widened, for example <3 x i8> -> <4 x i8>. > if (!VT.isPow2VectorType()) { > NumElts = (unsigned)NextPowerOf2(NumElts); > EVT NVT = EVT::getVectorVT(Context, EltVT, NumElts); > + while (!isTypeLegal(NVT)) { > + NumElts = (unsigned)NextPowerOf2(NumElts); > + NVT = EVT::getVectorVT(Context, EltVT, NumElts); > + } > return LegalizeKind(TypeWidenVector, NVT); > } > > Your patch is incorrect. We first need to widen to the next power...

I am trying to add an call to computeRegisterProperties in the ARM target. The problem is that, after adding it, llc fails with Assertion `isTypeLegal(MVT::f64) && "Target does not support FP?"' failed The assert is at TargetLowering.cpp:138. Why is FP required? Most ARMs don't have an FPU. Should I add a fake register class for MVT::f64? Thanks, Rafael

...t;EXT" part is probably irrelevant here, if that's >> > what's bugging you ;) >> >> Nevermind, grepping around shows this is specifically about >> ISD::EXTLOAD, in LegalizeLoadOps (LegalizeDAG.cpp). >> >> There's some code above, with an "isTypeLegal(SrcVT)" check, that >> tries to turn an EXTLOAD into LOAD+[SZ]EXT. I'm guessing that on your >> target, both the EXTLOAD from i8 and the i8 type are illegal? >> >> In that case, again, I don't know how one could legalize this. >> >> -Ahmed > >