search for: regvts

...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; }

Hi, I define a customized node with customized type. The job of this customized node is to move a value from one register class to another class. I find that if there is no use of the destination register, this node will be deleted from SDAG. For some reasons, I want to keep this node. So I attach mayStore attribute to this node and I hope it will not be deleted. However, it does not work like I

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

Hi, All, I'm trying to build a customized backend and I need to lower the formal arguments like this: There are several specific registers just for storing formal arguments. And also there are several general purpose registers for computation. If there is an instruction which uses parameters, I should first use a move instruction, which moves the value to general purpose register. For

Here is a series of patches replacing EVT with MVT at a number of places in TargetLowering. The last two patches are related cleanups in SelectionDAGBuilder. /Patrik Hägglund > git log --stat --reverse origin/master.. commit 8dabe3eb005360347eabb86a2e88c3b6e9098ed5 Author: Patrik Hägglund <patrik.h.hagglund at ericsson.com> Date: Tue Dec 4 10:37:37 2012 +0100 Change

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