similar to: Getting up to speed with llvm backends. Machine Instruction operands.

Hi, I think I've found a bug in this method. I ran it on an MI which already had two implicit-use operands, and which defined a register with a subregindex, ie reg::lo16. For the def-operand, with a subregindex, an implicit-use operand was added with this code: VirtUseOps.insert(VirtUseOps.begin(), MI.getNumOperands()); MI.addOperand(MachineOperand::CreateReg(VirtReg,

If I have an instruction which has many register and immediate operands, what's the difference between these two implementations to define the instruction in TableGen *.td file? (1) Similar to what has been done to complex X86 addressing mode. A single 32-bit immediate (i32) encodes how to add many MachineOperands to the MachineInstr object (With the help of functions in X86InstrBuilder.h).

On Oct 7, 2011, at 8:14 AM, Jonas Paulsson wrote: > Hi, > > I think I've found a bug in this method. > > I ran it on an MI which already had two implicit-use operands, and which defined a register with a subregindex, ie reg::lo16. > > For the def-operand, with a subregindex, an implicit-use operand was added with this code: > >

I'm getting this incompatible type assertion when I run tblgen on my .td files: llvm/include/llvm/Support/Casting.h:237: typename llvm::cast_retty<X, Y*>::ret_type llvm::cast(Y*) [with X = llvm::DefInit; Y = llvm::Init; typename llvm::cast_retty<X, Y*>::ret_type = llvm::DefInit*]: Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible

This shouldn't have parsed. movq (%gs), %r14 That's trying to use%gs as a base register which isn't valid. GNU assembler rejects it. And coincidentally llvm-mc started rejecting it on trunk late last week. That's probably why it printed as %ebp. I don't know if there is an instruction to read the base of %gs directly. Maybe rdgsbase, but that's only available on Ivy

All, The code generator operand class, MachineOperand, has an 8-bit TargetFlags field that the individual targets can use as they please. X86 and ARM use it to encode linker magic on symbol operands. It has been mentioned a couple of times on this list that it is not safe to use TargetFlags on register operands. This is because many target-independent passes are manipulating register operands

Hi Susan, Jakob just pointed me to 'MachineOperand::substPhysReg(unsigned preg, const TargetRegisterInfo& TRI)'. That substitutes the given physreg for a virtreg operand, taking the subregister index into account. That is what my examples have been doing manually. Using substPhysReg would allow you to tidy the Gcra code up slightly. - Lang. On Thu, Nov 15, 2012 at 11:21 AM, Lang

Hello, InstAlias does not allow tied operands (repeated operands) in the asm string to be matched. It seems this situation is explicitly prevented in AsmMatcherEmitter.cpp: if (!Hack) PrintFatalError(TheDef->getLoc(), "ERROR: matchable with tied operand '" + Tok + "' can never be matched!");

Thanks Lang, I'll try substPhysReg. I did try your latest code, and although it made the assembler errors go away, now some of my tests produce bad output when executed. I need to look into that some more... (I did change my "usedPregSet" to be ALL pregs used in the whole function, not just those in the current instruction, so the problem should not be the erroneous

Hi, On Instructions you can use checkEarlyTargetMatchPredicate() to check that the operands are the same. There's an example of that in MipsAsmParser.cpp for DATI and DAHI. I can't think of a reason TableGen couldn't be made to allow this for InstAlias too. > On 15 Dec 2017, at 02:12, via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > > InstAlias

> On Nov 29, 2018, at 02:02, Nicolai Hähnle <nhaehnle at gmail.com> wrote: > > On 27.11.18 19:01, Daniel Sanders wrote: >> ...Continued from the other email >> _Removing the defs section_ >> We can potentially infer quite a lot of the defs section but it requires both a complicated ruleset and that tblgen spends processing time doing the inferencing. That

Hi, I'm working on an LLVM backend for GPUs. One thing that is a little different about some GPUs is that instructions can take registers or 32-bit floating point immediates as arguments. I was wondering if there is a way to model this using tablegen, without having to define an instruction for each possible combination of registers and immediates (e.g. For ADD it would require four

Here's a reworked patch to mark instructions and operands as vector or scalar. It uses TableGen to infer the flags from types, allowing the user to override with a "let isVector = 0" clause. I decided to forego classifying MachineMemOperands for now in the interests of getting this piece in. I still think we should add type information to MachineMemOperands. Why throw away

Thanks Nicolai! > On Nov 9, 2018, at 02:55, Nicolai Hähnle <nhaehnle at gmail.com> wrote: > > Hi Daniel, > > Lots of good stuff in there! I especially like the design for specifying out-of-line predicates. I have a couple of small comments and one major one below. > > > On 09.11.18 02:42, Daniel Sanders via llvm-dev wrote: >> _Passing arbitrary data from

Hi, I am writing a small tool to gather some static statistics on machine code using LLVMs MachineInstr, etc., infrastructure. My current goal is to count the number of bytes of integer and floating point data being processed per iteration of a loop. Now I've ran into the problem that I can't find any obvious way to get the actual type of a MachineOperand. After some digging I noticed

Tom, There is no way to do this that I know of. Maybe David Greene or someone who hacks on Tablegen a lot would know. Micah > -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Tom Stellard > Sent: Thursday, November 03, 2011 10:23 AM > To: LLVM Developers Mailing List > Subject: [LLVMdev] Tablegen:

Hello, I am trying to create a machine instruction for "extractelement". I want to translate r <- extractelement v, 0 to mov r, v.x I was looking at the dag I can use and I found vector_extract. The inputs for this SDnode are a register and a iPtr constant. With that, I need to create 4 separate def's to extract element 0, 1, 2, and 3 and translate to v.x, v.y, v.z, and v.w. I

On Mon, Aug 20, 2012 at 04:30:13PM -0700, Jakob Stoklund Olesen wrote: > All, > > The code generator operand class, MachineOperand, has an 8-bit TargetFlags field that the individual targets can use as they please. X86 and ARM use it to encode linker magic on symbol operands. > > It has been mentioned a couple of times on this list that it is not safe to use TargetFlags on

But don't the defs for ADDR_RR and ADDR_RI also contain dags? def ADDR_RR : Addr< 2, "SelectAddrRegReg", (ops GPRC:$base, GPRC:$offsetreg) >; def ADDR_RI : Addr< 2, "SelectAddrRegImm", (ops GPRC:$base, i64imm:$offsetimm) >; Do I need to create some other intermediate node type for a shifted address? Phil On

Hi,   For a custom target, there is a pass to perform memory dependence analysis, where, i need to get memory pointer for "load instruction". I want to check the pointer alias behavior. I am getting this by considering the memoperands for the load instruction.   For "load instruction", Machine Instruction dumps as below:   vr12<def> = LD_Iri %vr2<kill>, 0;