similar to: [LLVMdev] Store patterns accepting i32 only?

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";

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 'regsw' are used to match

My architecture has an FPU, but uses integer registers to store floating-point values. So each register can store either an int or an IEEE float. I define a register class like this: def GR32 : RegisterClass<"MyArch", [i32, f32], 32, (sequence "R%u", 0, 32)>; So far so good. However, when I write a rule to store a register: def STORE32r : S32< (outs), (ins

LLVMers, The 2.4 pre-release is available for testing: http://llvm.org/prereleases/2.4/ If you have time, I'd appreciate anyone who can help test the release. Please do the following: 1) Download/compile llvm source, and either compile llvm-gcc source or use llvm-gcc binary. 2) Run make check, send me the testrun.log 3) Run "make TEST=nightly report" and send me the

Hi, I am writing a backend and having issues with properly lowering the result of getElementPtr ( specifically the add node that it generates). If we take this IR: %struct.rectangle = type { i24, i24 } ; Function Attrs: nounwind readonly define i24 @area(%struct.rectangle* nocapture readonly %r) #0 { entry: %width = getelementptr inbounds %struct.rectangle* %r, i16 0, i32 0 %0 = load i24*

Hi again, I'm finally getting some time to work on my m68k backend again. :) I was trying to solve the problem that loads from arbitrary addresses need to go through address registers. 68k allows flexible addressing similar to what the x86 can do, only that the adressing base has to reside in an address register: move.size[b/w/l] <Displacement>(Ax, Dx * Scale[1/2/4/8]), <Dest>

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,

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

2008/2/15, Andreas Fredriksson <deplinenoise at gmail.com>: > > I tried mocking this up using the following. (Base is what's returned as > the Ax in the move expression above when the DAG is constructed due to > SelectAddr().) > > SDOperand chain = CurDAG->getCopyToReg(Base, M68K::A3, Base); > Base = CurDAG->getCopyFromReg(chain, M68K::A3, MVT::i32);

Hi all, I am experiencing a problem with the representation of addresses in the x86_64 TableGen backend and was hoping someone can tell me if it is fixable. Any comments or hints in to send me in the right direction would be greatly appreciated. I am using LLVM version 3.8, commit 251286. I have an IR pass that stores metadata in the upper 32 bits of 64-bit pointers in order to implement

Hi Bruce, Thanks for you reply. I check the *.td files under the lib/Target/X86 folder, but have not got interesting findings. It requires some knowledge of LLVM backend to fully understand the *.td files. I will get some background and keep searching. Of course I appreciate if anyone with such experience can point the concrete locations. Regards, Hu Hong On 17 October 2016 at 22:20, Bruce

Hi Eli, Thanks, I’ll look into that then! Cheers, Taddeüs From: Friedman, Eli Sent: Wednesday, 2 August 2017 19:48 To: Taddeus; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Efficiently ignoring upper 32 pointer bits whendereferencing On 8/2/2017 9:03 AM, Taddeus via llvm-dev wrote: > Hi all, > > I am experiencing a problem with the representation of addresses in > the x86_64

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

Hi Chris, > On Wed, 6 Sep 2006, [UTF-8] Rafael Esp?ndola wrote: > > The ARM has some very powerful and complex addressing modes. For > > example, the data processing instructions (and, orr, add, ..) have > > an addressing mode that has 11 options (imm, reg, and 9 reg + some > > shift). > > I'm not sure exactly what the constraints you have are For those

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

Hello everyone, I would like to ask a question about the address calculation in TableGen. I replace a definition in MipsInstrInfo.td: def : Pat<(i32 (extloadi16_a addr:$src)), (LHu addr:$src)>; to: def : Pat<(i32 (extloadi16_a addr:$src)), (OR (LBu addr:$src), (SLL (LBu addr:($src+1)), 8))>; However, it failed to compiled. It seems that ($src+1) is a wrong representation in TableGen.

i'm getting a Could not infer all types in pattern! error in my backend. it is happening on the following instruction: VGETITEM: (set GPR:{i32:f32}:$rD, (extractelt:{i32:f32} VR:{v4i32:v4f32}:$rA, GPR:i32:$rB)). how do i make it use appropriate types? in other words if it is f32 then use v4v32 and if it is i32 then use v4f32. i'm not sure even where to start? any help is appreciated.

Hi, I am Georg, a student for Embedded System Design at the University of Applied Sciences Upper Austria, Campus Hagenberg. (https://www.fh-ooe.at/en/hagenberg-campus/studiengaenge/master/embedded-systems-design/) In some lectures at my university, a simple 16-bit CPU with a very small instruction set of only 24 instructions called PROL16 is used to teach CPU architecture and chip design. I

On Jul 13, 2009, at 10:02 AM, David Greene wrote: >>> - Tag instructons with source line information (customers really >>> want this). >> >> Right, that would be nice. This should be synthesizable from the >> DebugLoc on the instruction in the asm printer, no need to >> redundantly >> encode it into the comment field. > > Except the DebugLoc

Hi llvm-dev, >> The CopyFromReg->CopyToReg->CopyFromReg sequence doesn’t have the chains set correctly: the second CopyFromReg’s input chain isn’t connected to the CopyToReg’s output chain. (This appears to be the same problem in both graphs.) The DAG mentioned was generated by the SelectionDAGBuilder and as much as possible, we only modify the files within our target so I tried