search for: complexpattern

Currently tablegen emits a rather surprising match code for the following case: Suppose we have a pattern that uses a ComplexPattern to match an operand. This pattern then appears as a child pattern in a different pattern. Pattern 1: (N1 ComplexPattern:OP) Pattern 0: (N0 (N1 ComplexPattern:OP)) The match code for ComplexPattern is passed in N1 in Pattern 1 and N0 in Pattern 0. This means that ComplexPattern is always pass...

On Jan 1, 2008, at 9:29 PM, Evan Cheng wrote: > > On Dec 30, 2007, at 9:04 PM, Christopher Lamb wrote: > >> Currently tablegen emits a rather surprising match code for the >> following case: >> >> Suppose we have a pattern that uses a ComplexPattern to match an >> operand. This pattern then appears as a child pattern in a >> different pattern. >> Pattern 1: (N1 ComplexPattern:OP) >> Pattern 0: (N0 (N1 ComplexPattern:OP)) >> >> The match code for ComplexPattern is passed in N1 in Pattern 1 and >>...

On Dec 30, 2007, at 9:04 PM, Christopher Lamb wrote: > Currently tablegen emits a rather surprising match code for the > following case: > > Suppose we have a pattern that uses a ComplexPattern to match an > operand. This pattern then appears as a child pattern in a > different pattern. > Pattern 1: (N1 ComplexPattern:OP) > Pattern 0: (N0 (N1 ComplexPattern:OP)) > > The match code for ComplexPattern is passed in N1 in Pattern 1 and > N0 in Pattern 0. This means...

It seems that it's not allowed to two same 'ComplexPattern's in a 'def', because TableGen generate the same variable names for the two ComplexPatterns. If I understand the source code of TableGen correctly, it's not designed to use more than one ComplexPattern instance (no matter they are the same or not). In the following example, two ...

Hi, I was wondering if someone could explain precisely what the ComplexPattern tablegen class does? Here's the first line of the definition (from TargetSelectionDAG.td) for reference: class ComplexPattern<ValueType ty, int numops, string fn, list<SDNode> roots = [], list<SDNodeProperty> props = [],...

Alex schrieb: > It seems that it's not allowed to two same 'ComplexPattern's in a 'def', > because TableGen generate the same variable names for the two ComplexPatterns. > If I understand the source code of TableGen correctly, it's not designed to > use more than one ComplexPattern instance (no matter they are the same or not). I've run into...

...tISelEmitter. I hope this is a starting point for you, florian ps: We have a working compiler here that relies on these changes, so it does not seem to break anything, at least for our private backend. -------------- next part -------------- A non-text attachment was scrubbed... Name: multiple-complexpatterns.patch Type: text/x-patch Size: 2958 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20090115/fe4ad532/attachment.bin>

...if (InstPatNode && !InstPatNode->isLeaf() && + InstPatNode->getOperator()->getName() == "set") { because I'm unsure what it's for. When is a "set" node a leaf? BTW, the FastISelEmitter should be ignoring any instructions that have ComplexPatterns, so there shouldn't be a problem there. Also, it's only enabled for x86 right now. Dan

...> > (after optimization) > %reg1054<def>, %reg1033<def> = LDRD %reg1030, %reg0, 264, pred:14, pred:%reg0; mem:LD4[%uglygep10], mem:LD4[%uglygep2021] If I had to guess, I would think it's because of how LDR is defined: def addrmodepc : Operand<i32>, ComplexPattern<i32, 2, "SelectAddrModePC", []> { let PrintMethod = "printAddrModePCOperand"; let MIOperandInfo = (ops GPR, i32imm); } def LDR : AI2ldw<(outs GPR:$dst), (ins addrmode2:$addr), LdFrm, IIC_iLoadr, "ldr", "\t$dst, $addr",...

...y well be a leaf. in that case calling getOperator is not valid, because it asserts on !isLeaf: Record *getOperator() const { assert(!isLeaf()); return Operator; } so this check definitely should be there. but it is true, i should have split the patch into two pieces as it is not related to the ComplexPattern issue. sorry for that. florian

Has anybody used the Pattern class. We all use Pat and ComplexPattern but I can't find any examples of Pattern. I have some instructions that I'm currently treating as pseudos but I'd like to treat them as patterns with several instructions but this does not seem to work, at least I can't get it to work so far. I get an error: Cannot handle instruc...

Is it possible to use this operand class in an instruction that has a pattern defined? If so, can you write it with anything besides a ComplexPattern in the instruction's pattern DAG, to set it to a value? Can you refer to it at all? Or would it be added to the MachineInstr with the default value such that you could modify it later in the backend? If there is a non-ComplexPattern way to write this, can you provide an example? Thanks, Joe

I have two questions regarding MachineMemOperands and dependence information. Q1) I noticed that MachineMemOperands are lost when two LDRs are combined and a LDRD is generated in ARMPreAllocLoadStoreOpt:::RescheduleOps. (before optimization) %reg1033<def> = LDR %reg1030, %reg0, 4100, pred:14, pred:%reg0; mem:LD4[%uglygep10] %reg1054<def> = LDR %reg1030, %reg0, 4104, pred:14,

I'm interested in class Pattern. Classes Pat and ComplexPattern are used everywhere. ________________________________________ From: Triple Yang [triple.yang at gmail.com] Sent: Sunday, September 16, 2012 9:55 AM To: Kotler, Reed Cc: LLVM-Dev ‎[llvmdev at cs.uiuc.edu]‎ Subject: Re: [LLVMdev] Pattern class You might want to refer to lib/Target/Sparc/SparcInstr...

...> > %reg1054<def>, %reg1033<def> = LDRD %reg1030, %reg0, 264, pred:14, > pred:%reg0; mem:LD4[%uglygep10], mem:LD4[%uglygep2021] > > If I had to guess, I would think it's because of how LDR is defined: > > def addrmodepc : Operand<i32>, > ComplexPattern<i32, 2, "SelectAddrModePC", []> { > let PrintMethod = "printAddrModePCOperand"; > let MIOperandInfo = (ops GPR, i32imm); > } > def LDR : AI2ldw<(outs GPR:$dst), (ins addrmode2:$addr), LdFrm, > IIC_iLoadr, > "ldr", "\t$ds...

Hi All I'm having nightmares with FrameIndexes during my backend development :( I have ComplexPatterns defined for my two addressing modes (RR and RI). Most of the time, FrameIndex operands appear to be on load/store nodes, in which case everything works fine as my custom addressing modes matchers work fine. Unfortunately, I now have an add node which has a FrameIndex operand (this results from a...

You might want to refer to lib/Target/Sparc/SparcInstrInfo.td for examples of both Pat and ComplexPattern. Regards. 2012/9/16 Kotler, Reed <rkotler at mips.com>: > Has anybody used the Pattern class. We all use Pat and ComplexPattern but I > can't find any examples of Pattern. > > I have some instructions that I'm currently treating as pseudos but I'd like > to treat...

...32RegClass), ?:$rsrc, ?:$sampler, (as_i32imm ?:$mask), (as_i1imm ?:$unorm), (as_i1imm ?:$cachepolicy), (as_i1imm ?:$cachepolicy), 0, 0, 0, { 0 })>; which would be ideal. This seems to be because OPC_CheckInteger only checks for ConstantSDNode and not ConstantFPSDNode. So it was suggested to use ComplexPattern, so given: bool XXXDAGToDAGISel::SelectConstantFPSDNodeImmZero(SDValue In, SDValue &Src) const { if (ConstantFPSDNode *C = dyn_cast<ConstantFPSDNode>(In)) return C->isZero(); return false; } def ConstantFPSDNodeImmZero : ComplexPattern<f32, 0, "SelectConstantFPSDNodeI...

...cific opcode. I tried > adding special support for "either of the two constant opcodes" to the > matcher, but I could not see a good way to do it without making fundamental > changes to how patterns are matched. > > > I think you’ll have to define the matcher in C++ with ComplexPattern, > analogously to how the addressing mode selection logic works. This allows > you to specify multiple ISD nodes that it can match. > > > - Use the ISD::Constant opcode for absolute symbol constants, but > introduce a separate class for them. This also seemed problematic, as ther...

...data memories, each with its own load/store instructions but also has some instructions using both memories. I want to be able to access both memories in C-programs through the address space attribute. I have two ideas so far: Either: use two sets of addressing modes in InstrInfo.td: def ADDRrr_A : ComplexPattern<i16, 2, “SelectADDRrr_A", [], []>; def ADDRri : ComplexPattern<i16, 2, "SelectADDRri", [frameindex], []>; and def ADDRrr_B : ComplexPattern<i16, 2, "SelectADDRrr_B", [], []>; Or: do something in one of the lowering functions to catch load and stores, look...