search for: regvt

...argetInfo) const { if (ImplicitDefs.empty()) return MVT::Other; // Check to see if the first implicit def has a resolvable type. Record *FirstImplicitDef = ImplicitDefs[0]; assert(FirstImplicitDef->isSubClassOf("Register")); const std::vector<MVT::SimpleValueType> &RegVTs = TargetInfo.getRegisterVTs(FirstImplicitDef); if (RegVTs.size() == 1) return RegVTs[0]; return MVT::Other; }

...example, I add this node into SDAG when I want to move the formal argument from the specific register class to other register class. I implement it in LowerFormalArguments() like this: .... for (auto &VA : ArgLocs) { if (VA.isRegLoc()) { // Arguments passed in registers EVT RegVT = VA.getLocVT(); VReg = RegInfo.createVirtualRegister(&FOO::BRegsRegClass); RegInfo.addLiveIn(VA.getLocReg(), VReg); SDValue ArgIn = DAG.getCopyFromReg(Chain, dl, VReg, RegVT); SDValue ArgIn_copy = DAG.getNode(FOOISD::MOVE_FLAG , dl, MVT::i32, Chain, ArgIn); // this node...

Jakob Stoklund Olesen <stoklund at 2pi.dk> writes: > It appears that tablegen is inferring the 'type' of an individual > register by enumerating all the register classes it appears in. Some > things, like using implicit defs in SDNodes, only works for registers > with a unique type. My WIDE32 class caused GR32 registers to no > longer have a unique type, breaking

...(ImplicitDefs.empty()) return MVT::Other; > > // Check to see if the first implicit def has a resolvable type. > Record *FirstImplicitDef = ImplicitDefs[0]; > assert(FirstImplicitDef->isSubClassOf("Register")); > const std::vector<MVT::SimpleValueType> &RegVTs = > TargetInfo.getRegisterVTs(FirstImplicitDef); > if (RegVTs.size() == 1) > return RegVTs[0]; > return MVT::Other; > }

So I tried adding a new register class to the x86 target: def WIDE32 : RegisterClass<"X86", [i32, f32], 32, (add GR32, FR32)>; I thought this would be a harmless thing to do since the new register class is not being referenced anywhere. I was wrong, it caused all kinds of assertion failures from tablegen's isel pattern generator. It appears that tablegen is inferring the

Hi Rail, We used a very simple pattern expansion (actually, not a pattern fragment). For example, for AND, ADD (horizontal sum), OR and XOR of 4 elements we use something like the following TableGen structure: class HORIZ_Op4<SDNode opc, RegisterClass regVT, ValueType rt, ValueType vt, string asmstr> : SHAVE_Instr<(outs regVT:$dst), (ins VRF128:$src), !strconcat(asmstr, " $dst $src"), [(set regVT:$dst, (opc (rt (vector_extract(vt VRF128:$src), 0 ) ),...

...tor<CCValAssign, 16> ArgLocs; CCState CCInfo(CallConv, isVarArg, DAG.getMachineFunction(), ArgLocs, *DAG.getContext()); CCInfo.AnalyzeFormalArguments(Ins, CC_FOO); for (auto &VA : ArgLocs) { if (VA.isRegLoc()) { // Arguments passed in registers EVT RegVT = VA.getLocVT(); const unsigned VReg = RegInfo.createVirtualRegister(&FOO::PRegsRegClass); RegInfo.addLiveIn(VA.getLocReg(), VReg); SDValue ArgIn = DAG.getCopyFromReg(Chain, dl, VReg, RegVT); InVals.push_back(ArgIn); continue; } // assume the parameter reg...

...| 6 +++--- lib/Target/X86/X86ISelLowering.h | 4 ++-- 5 files changed, 30 insertions(+), 8 deletions(-) commit c2b741acf39b269946a85d7676045fe59e29b290 Author: Patrik Hägglund <patrik.h.hagglund at ericsson.com> Date: Thu Dec 6 10:25:43 2012 +0100 Change RegVT in BitTestBlock and RegsForValue, in SelectionDAGBuilder, to contain MVTs, instead of EVTs. lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp | 21 ++++++++++----------- lib/CodeGen/SelectionDAG/SelectionDAGBuilder.h | 4 ++-- 2 files changed, 12 insertions(+), 13 deletions(-) commit 2f58c92a...

This would be really cool. We have several instructions that perform horizontal vector operations, and have to use built-ins to select them as there is no easy way of expressing them in a TD file. Some like SUM for a ‘v4i32’ are easy enough to express with a pattern fragment, SUM ‘v8i16’ takes TableGen a long time to compute, but SUM ‘v16i8’ resulted in TableGen disappearing into itself for