similar to: Questions about load/store incrementing address modes

Thanks Steve, I will try this out. I hadn’t realised that TableGen was restricted to matching instructions with more than one output operand. I’m assuming that this is only a limitation for inferring an instruction from the patterns, because it does seem to manage schedules okay. Curiously, my memory Reg32+Reg16 pattern is very similar to yours (the 16-bit offset is sign-extended though):

----- Original Message ----- > From: "Bruce Hoult" <bruce at hoult.org> > To: "Johnny Val" <johnnydval at gmail.com> > Cc: "<llvmdev at cs.uiuc.edu>" <llvmdev at cs.uiuc.edu> > Sent: Thursday, October 23, 2014 8:31:35 AM > Subject: Re: [LLVMdev] Question regarding getElementPtr/Addressing modes in backend > > Many CPU

Hi Steve, Thanks for the tip regarding MIOperandInfo, I didn't think of that part of the tablegen description. Sadly, I did actually mean: r1 = *(i0 += m0). So increment i0 by m0. Read memory the memory location "pointed" to by i0. Store in r1. Sadly I am not too familiar with compiler terminology, so I don't know if there is a proper term for such a load. On Thu, Oct 23,

Thanks again for your help Steve, I’m thinking perhaps my “SelectADDRrr” pattern is inadequate. The sign-extension is at the hardware level, the code generator sees (should see) it as a 16-bit signed register value. My implementation is just: bool SHAVEISelDAGtoDAG::SelectADDRrr(SDValue &Addr, SDValue &Base, SDValue &Offset) { if ((Addr.getOpcode() == ISD::ADD) { Base

Hello. I fixed the bug reported in the previous post on this thread (<<llvm::MemSDNode::MemSDNode(unsigned int, unsigned int, const llvm::DebugLoc&, llvm::SDVTList, llvm::EVT, llvm::MachineMemOperand*): Assertion `memvt.getStoreSize() <= MMO->getSize() && "Size mismatch!"' failed.>>) The problem with this strange error reported comes from

Hi Hal, Our Architecture has indirect move instruction which increments the pointer implicitly and the target only has i8 type values. So the load of i16 will be converted to two i8 target loads wherein after the first load instruction, the pointer to the first i8 address will automatically increment to point to the next i8 value. So the post increment nature is in the Target. A normal

----- Original Message ----- > Hi Hal, > > > Our Architecture has indirect move instruction which increments > the > pointer implicitly and the target only has i8 type values. So the > load > of i16 will be converted to two i8 target loads wherein after the > first > load instruction, the pointer to the first i8 address will > automatically >

Hello. I wanted to inform that I fixed the bug from the previous email. The main reason for the bug was that I thought that the SDNode masked_gather is returning only 1 value, but it returns 2 (hence, I guess, the earlier reported, difficult to follow, error: "Assertion `New->getNumTypes() == 1"). masked_gather returns 2 values because: // SDTypeProfile -

Hi Hal, On Tuesday 01 October 2013 06:22 PM, Hal Finkel wrote: > ----- Original Message ----- >> Hi Hal, >> >> >> Our Architecture has indirect move instruction which increments >> the >> pointer implicitly and the target only has i8 type values. So the >> load >> of i16 will be converted to two i8 target loads wherein after the

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,

On Sep 7, 2010, at 10:48 AM, Akira Hatanaka wrote: > 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;

Hello, I'm trying to define in my new back end, in MyBackendInstrInfo.td file, a vector load instruction that takes an immediate address operand. (I got inspired from Mips' MSA SIMD extensions.) Could you please tell me what's the right way to do it? Here, the load class has $addrsrc which is a relative address with base a certain register and offset: class

On 7 April 2013 14:54, Sam Parker <S.Parker3 at lboro.ac.uk> wrote: > Hi Anitha, > > memri is just describing that the address contains two components, an > immediate and a register, and how to handle them in the instruction printer. > The STWU expects a memri operand, and that is what is passed from the Pat. > My confusion is how operands of STWU from "Pat

Sorry, this is the part in ARMLoadStoreOptimizer.cpp that creates a LDRD instruction. Ops.pop_back(); Ops.pop_back(); // Form the pair instruction. if (isLd) { MachineInstrBuilder MIB = BuildMI(*MBB, InsertPos, dl, TII->get(NewOpc)) .addReg(EvenReg, RegState::Define)

I'm trying to write a store pattern that accepts both i32 and f32, however, when tablegen generates the code, it only generates the code for i32 only. def ADDR : ComplexPattern<i32, 2, "SelectADDR", [], []>; def MEM : Operand<i32> { let PrintMethod = "printMemOperand"; let MIOperandInfo = (ops GPR, GPR); } def global_st :

Hi all, I started to write an LLVM backend for custom CPU. I created XXXInstrInfo but there are some problems. I searched for it but I couldn't find anything. Can anyone help me? include "XXXInstrFormats.td" def simm16 : Operand<i32> { let DecoderMethod = "DecodeSimm16"; } def mem : Operand<i32> { let PrintMethod = "printMemOperand"; let

Hello > Finally, I don't know how to describe following instructions in > MCoreInstrInfo.td, because of its variable ins/outs. Or what other files > should I use to finish this description? Do you need the isel support for them? If yes, then you should custom isel them. iirc ARM and SystemZ backends have similar instructions, while only the first one supports full isel for them. In

On Sep 23, 2008, at 10:44 AM, Villmow, Micah wrote: > I’m trying to write a store pattern that accepts both i32 and f32, > however, when tablegen generates the code, it only generates the > code for i32 only. > > def ADDR : ComplexPattern<i32, 2, "SelectADDR", [], []>; > def MEM : Operand<i32> { > let PrintMethod = "printMemOperand";

Hi, We have an architecture where the indirect move instruction implicitly increments the pointer value after the move. We have Instruction format and pattern for this type of instructions. How to encode the information that the pointer is incremented? Thanks and regards, Shashidhar

We discovered what is happening. SDAGCombiner essentially looks at various combinations of nodes to do with vectors, and when it can, it creates a vector shuffle. The problem is, that our vector shuffle lowering builds new trees with vector element, or vector sub-vector insert sequences. The generic DAGCombiner, reconstructs these into a new shuffle, and so the loop continues - we reduce it,