search for: xyziseldagtodag

...I need the result to be: m0 = 4 r1 = *(i0 += m0) (offset is stored in a register(m0), and modifies the original pointer) rather than r1 = *(i0 + 4) (immediate) (The specific registers numbers don't matter). I'm not sure how to achieve that. Currently addr gets matched in SelectAddr in XYZISelDAGToDAG.cpp. It will match the add node and "combine" (I'm not sure this is the correct terminology) it into my LDR node. The result of this can be seen sched.png So instead of that TargetConst<4> I need a something that copies 4 into an M register, and then LDR uses that. I'm not...

Hi, I used 2 different compilers to compile the same IR for the same custom target. The LLVM IR code is define i32 @_Z9test_mathv() #0 { %a = alloca i32, align 4 %1 = load i32, i32* %a, align 4 ret i32 %1 } Before instruction selection, the Selection DAGs are the same: Optimized legalized selection DAG: %bb.0 '_Z9test_mathv:' SelectionDAG has 7 nodes: t0: ch = EntryToken t4:

Hello. After "Initial selection DAG" stage I get a DAG with node t14: ch = store<(store 4 into %ir.p45, align 8, addrspace 1)> t10, FrameIndex:i32<2>, FrameIndex:i32<3>, undef:i32 1. Where 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

..., and modifies the > original pointer) > > > > rather than > > > > r1 = *(i0 + 4) (immediate) > > > > (The specific registers numbers don't matter). > > > > I'm not sure how to achieve that. Currently addr gets matched in > SelectAddr in XYZISelDAGToDAG.cpp. It will match the add node and "combine" > (I'm not sure this is the correct terminology) it into my LDR node. The > result of this can be seen sched.png > > > > So instead of that TargetConst<4> I need a something that copies 4 into > an M register, an...

...> > the original pointer) > > > > rather than > > > > r1 = *(i0 + 4) (immediate) > > > > (The specific registers numbers don't matter). > > > > I'm not sure how to achieve that. Currently addr gets matched in > > SelectAddr in XYZISelDAGToDAG.cpp. It will match the add node and > > "combine" (I'm not sure this is the correct terminology) it into > > my LDR node. The result of this can be seen sched.png > > > > So instead of that TargetConst<4> I need a something that copies 4 > > into a...

Hello. Could you please help me solve the following LLC bug happening at instruction selection time: ISEL: Starting pattern match on root node: t172: ch = store<ST64[FixedStack6]> t0, t6, FrameIndex:i64<6>, undef:i64 Initial Opcode index to 157 Skipped scope entry (due to false predicate) at index 162, continuing at 236 Match failed at

...ere in the code should I look into? It could be implemented in a couple of places. Most likely is that XYZInstrInfo.td (or some related TableGen file) defines a ComplexPattern that is used by the LDWI instruction definition. That ComplexPattern tells pattern matching to call a specific function in XYZISelDAGToDAG.cpp when deciding what to use for the LDWI operands. That C++ function is probably what looks for an FrameIndex node and has been taught that it can be folded into the load. If you just grep the target's code for FrameIndex or frameindex you should find it pretty quickly though, even if they u...

...;s probably > what you want so no need to change anything. > > After that, LLVM will try to select the FrameIndex itself (which > you'll need to support anyway so that you can pass a pointer to a > local variable between functions). > > Generally this seems to be handled by XYZISelDAGToDAG.cpp, which > converts an ISD::FrameIndex into an appropriate arithmetic instruction > 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 operan...