similar to: MC Assembler / tablegen: actually parsing variable_ops

On Mar 19, 2010, at 10:28 AM, Chris Lattner wrote: > > On Mar 19, 2010, at 7:46 AM, Jakob Stoklund Olesen wrote: > >> Hi, >> >> After Bob fixed the two-address format of the ARM ldm/stm instructions, a problem remains. The load multiple instruction looks like: >> >> // A list of registers separated by comma. Used by load/store multiple. >> def

On Mar 19, 2010, at 7:46 AM, Jakob Stoklund Olesen wrote: > Hi, > > After Bob fixed the two-address format of the ARM ldm/stm instructions, a problem remains. The load multiple instruction looks like: > > // A list of registers separated by comma. Used by load/store multiple. > def reglist : Operand<i32> { > let PrintMethod = "printRegisterList"; > }

Hi, After Bob fixed the two-address format of the ARM ldm/stm instructions, a problem remains. The load multiple instruction looks like: // A list of registers separated by comma. Used by load/store multiple. def reglist : Operand<i32> { let PrintMethod = "printRegisterList"; } def LDM : AXI4ld<(outs), (ins addrmode4:$addr, pred:$p, reglist:$dsts,

On Mar 19, 2010, at 11:04 AM, Jakob Stoklund Olesen wrote: >>> The description should only have 4 operands + variable_ops. >>> >>> How can you specify a named, variable list of output operands? >> >> Why do you need to do this? You currently can't do it. > > Because an instruction like LDM loads a variable number of registers. When it specifies

Hi Micah, the register use list gets dropped by the instruction selector because you didn't specify "variable_ops" in the input operand list of your CALL instruction. It has to look like this: (ins calltarget:$dst, variable_ops) Regards, Christoph

On 25/07/12 12:14, Paul Shortis wrote: > Thanks Richard, > > You're correct, they are similar. In the XCoreInstrInfo.td patterns > what I'm struggling with is why this .... > > def BL_lu10 : _FLU10< > (outs), > (ins calltarget:$target, variable_ops), > "bl $target", >

Hello, I'm currently working on a rich disassembler for some ARM/Thumb environment. I wanted to keep most classes independent of the architecture, so I use MCInstrInfo and MCInstrAnalysis to find branch instructions (and other instructions writing to the program counter) and to differentiate between register definitions and uses to track all instructions the branch depends on. This works

Hi Chris, Chris Lattner wrote: >> 2) Line 369 of PPCInstrInfo.td, we declare the non-callee saved registers. >> However, Linux and Darwin do not have the same set >> of non-callee saved registers. I don't know how to make the if(isDarwin) test >> in here >> > > Take a look at ARM/ARMRegisterInfo.td for an example of this I tried to define Defs just

Hallo, I worked on how to handle the distinction between variadic defines and uses and my current solution is this: I introduce a new dag item in Instruction called VariadicOperandList, which by default is undefined. It keeps a marker variable_* and all operands which are placeholders for variable lists (like 'reglist' on ARM). I think it's the cleanest solution to keep them in a

Am Mittwoch, 26. September 2012, 11:18:20 schrieb Jakob Stoklund Olesen: > Hi Christoph, > > As you noticed, MCInstrDesc doesn't distinguish between variadic uses and > defs. Since variadic instructions will always require some kind of special > handling, it doesn't seem worthwhile to make the model more detailed. I don't see what makes them so different from other

On 25/07/12 18:21, Richard Osborne wrote: > On 25 Jul 2012, at 04:49, Paul Shortis wrote: > > >> Hello, >> >> I'm considering creating an LLVM backend for a 16 bit processor and >> modelling it around the (experimental) MSP430 back end. >> >> When reviewing MSP430InstrInfo.td I see >> >> def MSP430Wrapper :

On Sat, 14 Oct 2006, Roman Levenstein wrote: >> On Sat, 14 Oct 2006, Roman Levenstein wrote: >>> Is it possible to dynamically define implicit defs for some >>> instructions? >> >> Yes! This is what explicit operands are :). Specifically, if you >> want to >> vary on a per-opcode basis what registers are used/def'd by the >> instruction,

Hi Serge, Thanks for your help. I have looked at the change log, and so far as I can tell, my implementation is pretty much identical to all of the in-tree targets, but I’m missing something and can’t see what it is. I have simplified my TD description to just: def MyCallseqStart : SDNode<"ISD::CALLSEQ_START", SDCallSeqStart<[SDTCisVT<0, i32>,

Hi All, I wrote a very crude and simple AsmParser for my backend. llvm-tablegen also generates asm-matcher .inc file without any error. I have included the .inc file in my class for AsmParser. However, while building llvm, in linking stage for LTO, i am getting error - undefined reference to functions - ComputeAvailableFeatures, MatchInstructionImpl, MatchRegisterName and

On Sep 24, 2012, at 6:39 PM, Christoph Grenz <christophg+llvm at grenz-bonn.de> wrote: > Is it possible to extend LLVM to check if 'variable_ops' is in 'ins' and/or > 'outs' in tablegen, so that MCInstrDesc could provide something like > hasVariadicDefs() and hasVariadicUses()? > > That way handling variadic instructions when disassembling would be

Hi, I've been hitting my head to wall two days now. This is practically my first contact with InstrInfo.td files. Is there any tutorial how to make this kind of stuff? Or should I just keep on studying Sparc and other backends? So I added new intrinsic to llvm/include/llvm/TCEInstrinsics.td: def int_tce_customop : Intrinsic<[llvm_void_ty, llvm_ptr_ty, llvm_vararg_ty], [],

I think the easiest thing for you to do is to define a separate CALL instruction with a different set of Defs. This instruction should only be selected when the predicate isMacho is true. Also update PPCRegisterInfo.cpp getCalleeSavedRegs() to return a different list when subtarget->isMachoABI() is true. Evan On Feb 14, 2007, at 7:19 AM, Nicolas Geoffray wrote: > Hi Chris, >

Hi Chris, Thanks for your response. > On Sat, 14 Oct 2006, Roman Levenstein wrote: > > Is it possible to dynamically define implicit defs for some > > instructions? > > Yes! This is what explicit operands are :). Specifically, if you > want to > vary on a per-opcode basis what registers are used/def'd by the > instruction, you can just add those registers

Using LLVM v5, my Cone compiler (https://github.com/jondgoodwin/cone) automatically directly generated all functions as named and exported for both wasm text and binary files (not using clang/lld etc, but using the API). Upgrading to LLVM v7, generated wasm object files now fail, exhibiting markedly different behavior, behavior that varies between the text and binary files. For example, the

Hi, it looks like old-style code generators can no longer work with LLVM CVS, because: 1. The TableGen uses the DAG from instruction to computed the number of operands written in generated tables, and when there's no DAG, writes 0. 2. MachineInstructions::addRegOperand checks for maximum number of operands. So, when not using DAGS in TableGen input, addRegOperand asserts on adding the very