search for: targetframeindex

Hi! I'm making a strange observation in my backend, that ends in illegal code: Version 1: - I lower FrameIndex to TargetFrameIndex (nothing special) - I generate a special address-register ADD instruction in eliminateFrameIndex() to write FramePointer + offset into a new address-register - I use explicit load and store and address-registers in my target instruction patterns: eg (store (add (load AddressRegs:$a), DataRegs:$b)...

...tGlobalAddress:i32<float* @x3> 0, undef:i16 t26: f32,ch = load<Volatile LD4[@x4](tbaa=<0x3dbe418>)> t25:1, TargetGlobalAddress:i32<float* @x4> 0, undef:i16 t29: ch,glue = callseq_start t26:1, TargetConstant:i16<4> t31: ch,glue = CLPISD::COPY_TO_CALLEE_A t29, t23, TargetFrameIndex:i16<0>, t29:1 t33: ch,glue = CLPISD::COPY_TO_CALLEE_A t31, t24, TargetFrameIndex:i16<1>, t31:1 t35: ch,glue = CLPISD::COPY_TO_CALLEE_A t33, t25, TargetFrameIndex:i16<2>, t33:1 t37: ch,glue = CLPISD::COPY_TO_CALLEE_A t35, t26, TargetFrameIndex:i16<3>, t35:1 t39: ch,gl...

...6 > >   t26: f32,ch = load<Volatile LD4[@x4](tbaa=<0x3dbe418>)> t25:1, > TargetGlobalAddress:i32<float* @x4> 0, undef:i16 > >   t29: ch,glue = callseq_start t26:1, TargetConstant:i16<4> > >   t31: ch,glue = CLPISD::COPY_TO_CALLEE_A t29, t23, > TargetFrameIndex:i16<0>, t29:1 > >   t33: ch,glue = CLPISD::COPY_TO_CALLEE_A t31, t24, > TargetFrameIndex:i16<1>, t31:1 > >   t35: ch,glue = CLPISD::COPY_TO_CALLEE_A t33, t25, > TargetFrameIndex:i16<2>, t33:1 > >   t37: ch,glue = CLPISD::COPY_TO_CALLEE_A t35, t26,...

Hi, Is there a kind of scope mechanism in the instruction lowering pattern language in order to control where instructions are inserted or how they are later reordered during the SelectionDiag linearization? I know the glue chain that stick instructions together. But such mechanism in not provided in instruction lowering pattern. I'm facing many situations where some patterns are lowered into

...16 > >   t26: f32,ch = load<Volatile LD4[@x4](tbaa=<0x3dbe418>)> t25:1, > TargetGlobalAddress:i32<float* @x4> 0, undef:i16 > >   t29: ch,glue = callseq_start t26:1, TargetConstant:i16<4> > >   t31: ch,glue = CLPISD::COPY_TO_CALLEE_A t29, t23, > TargetFrameIndex:i16<0>, t29:1 > >   t33: ch,glue = CLPISD::COPY_TO_CALLEE_A t31, t24, > TargetFrameIndex:i16<1>, t31:1 > >   t35: ch,glue = CLPISD::COPY_TO_CALLEE_A t33, t25, > TargetFrameIndex:i16<2>, t33:1 > >   t37: ch,glue = CLPISD::COPY_TO_CALLEE_A t35, t26,...

...0x26761c8: <multiple use> 0x2674b88: v4i32 = vector_shuffle 0x2672a20, 0x26761c8<2,3,u,u> [ORD=5] [ID=-3] 0x2671ec8: v4i32 = add 0x2672a20, 0x2674b88 [ORD=6] [ID=-3] 0x2672600: i32 = Register %R11 [ID=-3] 0x26438b0: <multiple use> 0x26760c0: i32 = TargetFrameIndex<2> [ID=-3] 0x2674fa8: ch = lifetime.end 0x26438b0, 0x26760c0 [ORD=10] [ID=-3] 0x2675a90: i32 = TargetFrameIndex<1> [ID=-3] 0x2674a80: ch = lifetime.end 0x2674fa8, 0x2675a90 [ORD=11] [ID=-3] 0x26752c0: i32 = TargetFrameIndex<0> [ID=-3] 0x2671fd0...

Hi Tim, >That C++ function is probably what looks for an FrameIndex node and >has been taught that it can be folded into the load. How do you teach a function that a node can be folded into an instruction? ________________________________ From: Tim Northover <t.p.northover at gmail.com> Sent: Monday, January 21, 2019 11:52 PM To: Josh Sharp Cc: via llvm-dev Subject: Re: [llvm-dev]

...here does it come from? Can I do anything to make it not appear? 2. If not, how do I change it so that the operand being stored would be first loaded into a register, and that register would be used instead? Like ch = StoreStackF<Mem:(store 4 into %ir.p45, align 8, addrspace 1)> Register:%1, TargetFrameIndex:i32<3>, t10 Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190624/9c7d3784/attachment.html>

...rameIndex:i16<0>, undef:i16 t72: f32 = CLPISD::LOAD_VECTOR_EXTRACT_o t57:1, FrameIndex:i16<0>, Constant:i16<0> t62: ch = llvm.clp.writeapb.f32 t58:1, TargetConstant:i16<397>, Constant:i32<24575>, t72 t73: ch = MOVATO_B_oo t53, TargetFrameIndex:i16<1>, t53:1 t57: v2f32,ch = LOAD_AB_o TargetFrameIndex:i16<0>, t73 t58: v2f32,ch = LOAD_AB_o TargetFrameIndex:i16<0>, t57:1 t61: i32,ch = LOAD_A_i TargetConstant:i32<24575>, t58:1 t72: f32 = LOAD_A_o TargetFrameIndex:i16<0>...

...DNode>(getValue(Alloca).getNode());* GFI->addStackRoot(FI->getIndex(), TypeMap); } *return* 0; Specifically, the cast from SDNode to FrameIndexSDNode fails because the node type is DYNAMIC_STACKALLOC, while this code is expecting the node type to be "FrameIndex" or "TargetFrameIndex". (I don't know what either of these mean, I'm just telling you what the debugger is telling me.) Here's what the IR looks like: %gc_root = alloca %tart.collections.KeyError*, align 8, !dbg !55084 store %tart.collections.KeyError* %7, %tart.collections.KeyError** %gc_root, al...

...like to understand how register allocation works in the case where an instruction is folded into another one. Where in the code would be a good place to start looking at? After ISEL, one of the instructions has another instruction folded into it, which looks like this t1: i32,i1,i1,i1,i1 = ADDRR TargetFrameIndex:i32<0>, MOVRI:i32,i1,i1 But during the 'Assembly Printer' pass, when emitting the assembly for ADDRR, the assertion at the beginning of getRegisterName() in XXXGenAsmWriter.inc fails because RegNo is 0. I'd like to know how that happened. Thanks. -------------- next part -------...

...());* GFI->addStackRoot(FI->getIndex(), TypeMap); > } > *return* 0; > > Specifically, the cast from SDNode to FrameIndexSDNode fails because the > node type is DYNAMIC_STACKALLOC, while this code is expecting the node type > to be "FrameIndex" or "TargetFrameIndex". (I don't know what either of these > mean, I'm just telling you what the debugger is telling me.) > > Here's what the IR looks like: > > %gc_root = alloca %tart.collections.KeyError*, align 8, !dbg !55084 > store %tart.collections.KeyError* %7, %tart.collect...

...---- next part -------------- Initial selection DAG: BB#0 '_Z3fn2v:entry' SelectionDAG has 122 nodes: t4: i64 = GlobalAddress<void (%class.F*)* @_Z10EmitLValuev> 0 t10: i64 = add Register:i64 %X1, Constant:i64<32> t0: ch = EntryToken t3: ch = lifetime.start t0, TargetFrameIndex:i64<1> t7: ch,glue = callseq_start t3, TargetConstant:i64<32>, TargetConstant:i64<0> t12: ch,glue = CopyToReg t7, Register:i64 %X3, FrameIndex:i64<1> t16: ch,glue = PPCISD::CALL_NOP t12, TargetGlobalAddress:i64<void (%class.F*)* @_Z10EmitLValuev> 0, Register:i6...

...yToReg t0, Register:i32 $r4, t4 t7: ch = UISD::Ret t6, Register:i32 $r4, t6:1 But after it, one has 1 more node than the other compiler 1 ===== Instruction selection ends: Selected selection DAG: %bb.0 '_Z9test_mathv:' SelectionDAG has 8 nodes: t0: ch = EntryToken t1: i32 = add TargetFrameIndex:i32<0>, TargetConstant:i32<0> t4: i32,ch = LDWI<Mem:(dereferenceable load 4 from %ir.a)> t1, t0 t6: ch,glue = CopyToReg t0, Register:i32 $r4, t4 t7: ch = JLR Register:i32 $r4, t6, t6:1 compiler 2 ===== Instruction selection ends: Selected selection DAG: BB#0 '_Z9test...

...ion > that can offset from SP. That gets lowered to actual known offsets > later on, in exactly the same way loads and stores are. > > It's probably done in C++ rather than TableGen because the operands of > these resulting instructions often look pretty weird (for example a > TargetFrameIndex instead of a register). That's mostly speculation > though, I haven't tried to write a bare frameindex pattern. > > Cheers. > > Tim. > On Mon, Jun 24, 2019 at 4:14 PM Krzysztof Parzyszek <kparzysz at quicinc.com> wrote: > FrameIndex values come from objects th...

...I am currently having a hard time extracting the offset in the FrameIndex node. I have also read (From “Using frameindex in a pattern” llvm-dev archive, referring to the Sparc target) that adding frameindex into the def addr : Complex Pattern<…,”SelectAddr”,…> would only translate it into a targetframeindex with an offset of 0. - In the AVR target, the ISD::FrameIndex has a custom select transforming it into an AVR:FRMIDX node and then later processed in the eliminateFrameIndex. Is this equivalent to the process I am trying to do? - What is the expected output process for a FrameIndex node...

Hi, I've been trying to teach LLVM that pointers are 128-bit long, which segfaults with some seemingly unrelated stacktrace when I try to take an address of a variable. Since stack saving and loading seems to work fine, I dare to assume the instruction causing problems there is leaq. Now I've done a search for leaq of the entire LLVM codebase with no success and I'd like to know which

Hello everyone, I wanted to attach a node without affecting the present nodes in any way. I tried to use MVT::Glue for that but I think I'm missing something as I could not achieve the below state. LUI LUI | | ADDI ----GLUE---- ADDI | store I've few question about this and Glue node in general, I'll be happy to get some help on

Evan Cheng wrote: > > On Dec 3, 2007, at 12:53 PM, Vladimir Prus wrote: > >> >> Suppose I have a target that does not have register+constant >> addressing mode. Then, I have DAG like: >> >> (store ..., (frameindex)) >> >> Targets like SPARC have the following patterns to catch this: >> >> def ADDRri : ComplexPattern<i32, 2,

...; [ORD=8] 0x3eabb70: ch = TokenFactor 0x3eac5c0, 0x3eac4b8, 0x3eabf90, 0x3eabe88 [ORD=8] 0x3ea4e20: <multiple use> 0x3ea48f8: <multiple use> 0x3ea44d8: i32 = MOVHI 0x3ea48f8 0x3ea4f28: ch,glue = CopyToReg 0x3eabb70, 0x3ea4e20, 0x3ea44d8 [ORD=9] 0x3ea7228: i32 = TargetFrameIndex<0> 0x3ea8d60: i32 = TargetConstant<12> 0x3ea48f8: i32 = TargetConstant<0> 0x3ea4c10: i32 = TargetConstant<4> 0x3eac1a0: i32 = TargetConstant<8> 0x3ea4b08: i32 = TargetFrameIndex<2> 0x3eac3b0: i32 = TargetFrameIndex<1> 0x3ea4e20: <m...