similar to: [LLVMdev] [PATCH] Handle tied sub-operands in AsmMatcherEmitter

Hi Jim, > Thank you for looking at this. Apologies again for taking > unjustifiably long to get back to you. This is really good stuff and > I very much want to see this go in. I like it enough I’m going to > try to talk you into doing even more work on improving this code. ;) > > Fair warning up front: You’re digging into some pretty fundamental > problems in how the

Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote on 25.04.2013 18:58:05: > On Apr 25, 2013, at 4:44 AM, Ulrich Weigand <Ulrich.Weigand at de.ibm.com> wrote: > > > Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote on 24.04.2013 23:47:54: > > > >> I would like to add one more case here: Fixed register operands. > >> > >> Some

Hi, I want to encode Loongson ISA initially https://gist.github.com/xiangzhai/8ae6966e2f02a94e180dd16ff1cd60ac gslbx           $2,0($3,$4) It is equivalent to: dadd $1, $3, $4 lb $2,0($1) I just use  mem_simmptr  as the default value of  DAGOperand MO , because  MipsMemAsmOperand  use  parseMemOperand  to parse general  MemOffset  and only *one*  AnyRegister , for example: 0($1) But 

On Apr 23, 2013, at 11:06 AM, Jim Grosbach <grosbach at apple.com> wrote: > There are two core issues. First, the tied operands are an artifact of the way we do instruction selection for the compiler. They’re how we represent read-modify-write operands, basically. The assembler shouldn’t have to know or care about them at all. Specifically, they shouldn’t even be represented at all as an

On Apr 25, 2013, at 4:44 AM, Ulrich Weigand <Ulrich.Weigand at de.ibm.com> wrote: > Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote on 24.04.2013 23:47:54: > >> I would like to add one more case here: Fixed register operands. >> >> Some instructions, like x86's MUL and DIV, take operands in fixed >> registers. Currently, we handle that with COPY

Jakob Stoklund Olesen <stoklund at 2pi.dk> wrote on 24.04.2013 23:47:54: > I would like to add one more case here: Fixed register operands. > > Some instructions, like x86's MUL and DIV, take operands in fixed > registers. Currently, we handle that with COPY instructions to and > from the fixed registers, but that is making code motion passes more > complicated than

GCC-style inline assembly is notoriously hard to write correctly, because it is the user's responsibility to tell the compiler about the requirements of the assembly (inputs, output, modified registers, memory access), and getting this wrong results in silently generating incorrect code. This is also dependent on register allocation and scheduling decisions made by the compiler, so an inline

Hello. I have problems specifying vector instructions with immediate values in TableGen. I wrote the following specification (I got inspired from the MSA vector instructions for the Mips back end): class MSA_I16_FMT<bits<9> opcode>: MSAInst { bits<16> s16; let Inst{31-23} = opcode; let Inst{26-11} = s16; }

Hi all. I'm looking for some way to do code analysis with LLVM. Can someone please give me a hint, if it is possible to query an MCInst for what are input operands and what are output operands? Small example. Consider we have an instruction: str r1, [sp, #8] Being mapped into MCInst instance it has the following operands: <MCOperand Reg:61> <-- maps to reg r1

Hi In my MC6809 backend, in llvm/lib/Target/MC6809/InstPrinter/MC6809InstPrinter.cpp, I have the routine void MC6809InstPrinter::printPCRelImmOperand(const MCInst *MI, unsigned OpNo, raw_ostream &O) { const MCOperand &Op = MI->getOperand(OpNo); ZZ if (Op.isImm()) { int64_t Imm = Op.getImm() + 2; <<<======================== O << "$"; if (Imm

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

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

I'm working on a disassembler for hexagon (vliw) architecture and I would like to add an additional operand type, "kAux" to the MCOperand class. The reason for this is that each insn has parse bits which are not explicit operands and have differing meanings based on the insn's location within the packet and the number of insns inside the packet. In order for the disassembler

On 06/25/2013 04:46 PM, Jim Grosbach wrote: > Hi Sid, > > This feels like it’s exposing too much of the disassembler internals > into the MCOperand representation. I’m not sure I follow why that’s > necessary. Can you elaborate a bit? > A packet contains 1-4 insns and until the contents of the entire packet are known the meaning of any individual insn is not known with 100%

Hi Sid, This feels like it’s exposing too much of the disassembler internals into the MCOperand representation. I’m not sure I follow why that’s necessary. Can you elaborate a bit? -Jim On Jun 25, 2013, at 8:24 AM, Sid Manning <sidneym at codeaurora.org> wrote: > > I'm working on a disassembler for hexagon (vliw) architecture and I would like to add an additional operand type,

Hello everyone, I'm a newbie of llvm. I'm trying to insert Intel MPX instruction BNDCU with BuildMI. I add my machinefunctionpass at addPreEmitPass2. Here is the code of insertion: BuildMI(MBB, MI, DL, TII->get(X86::BNDCU64rr)).addReg(X86::BND2, RegState::Define).addReg(X86::R10); And here is to stack track when I compiler program with modified llc:

Hello everyone, I'm working on a MachineFunctionPass that inserts a list of instructions into an Module so a later Pass can work on them. To do so I load a dummy .ll file created from a main stub, create the needed function stubs (ModulePass), insert Blocks and create instructions using BuildMI. I started with branch instructions:     const TargetMachine &TM = MF.getTarget();

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

The size suffix thing is a weird quirk in our assembler I should look into fixing. Instructions in at&t syntax usually have a size suffix that is often optional For example: add %ax, %bx and addw %ax, %bx Are equivalent because the register name indicates the size. but for an instruction like this addw $1, (%ax) There is nothing to infer the size from so an explicit suffix is

Thank you for your help Tom you are totally right with the registers but the command you suggest also doesn't work. After some research I found the following thread on the mailing list: http://lists.llvm.org/pipermail/llvm-dev/2017-February/110086.html With your help and the information about the condition codes I was able to resolve the error:         BuildMI(BB, BB.end(), DL,