similar to: [LLVMdev] how to annotate assembler

On 02.03.2012, at 09:20, Konstantin Vladimirov wrote: > Hi, > > In GCC there is one useful option -dp (or -dP for more verbose output) > to annotate assembler with instruction patterns, that was used when > assembler was generated. For example: The internal "-mllvm -show-mc-inst" option is probably as close as you can get. $ clang -S -O0 test.c -mllvm -show-mc-inst -o

Hi, Thank you, it is just what I need. But... it doesn't work for me: $ clang -S -O0 test.c -mllvm -show-mc-inst error: unknown argument: '-show-mc-inst' $ clang --version clang version 1.1 (branches/release_27) Target: x86_64-pc-linux-gnu Thread model: posix May be I need LLVM with higher version, or mention something in configure options? On Fri, Mar 2, 2012 at 4:32 PM,

Hi Tim, I'm sorry to bother you again. Since I have met the problem, how to check used registers and avoid clobbering live registers, which you mentioned in the email. I am working in the function X86InstrInfo::storeRegToStackSlot, which is in lib/Target/X86/X86InstrInfo.cpp. And I have an extra problem, may I use MOV64mr and two addReg to set two registers as its arguments? I want to use

Thanks for your help! I'm much more clear about this problem. Will 2018-04-13 17:53 GMT+08:00 Tim Northover <t.p.northover at gmail.com>: > Hi Will, > > On 13 April 2018 at 09:50, Will Lester via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > I have used BuildMI to build a MachineInstr. But it seems that a call > > MachineInstr only has one parameter

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

Hello, I'm trying to understand the relationship between MachineMemOperand and, on X86, memory operands of machine instructions. The latter seem to be operands held in order by the MachineInstr, from an offset onwards - Base, Scale, Index, Displacement, Segment. The former, if I understand it correctly, is used to hold a relationship back to IR load/store instructions. Is it possible to have

Hello Mircea, > On 8 Mar 2018, at 18:52, Mircea Trofin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello, > > I'm trying to understand the relationship between MachineMemOperand and, on X86, memory operands of machine instructions. The latter seem to be operands held in order by the MachineInstr, from an offset onwards - Base, Scale, Index, Displacement,

Thanks for the details! How should we think of the case where an instruction has memory operands (in the sense that X86II::getMemoryOperandNo >=0), but doesn't have MachineMemOperands? I'm seeing an example in the case of __builtin_prefetch (lowered via SelectionDAG::getMemIntrinsicNode, which produces a MachineMemOperand) vs __builtin_ia32_gatherpfdpd, lowered through getPrefetchNode

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 

A question for LLVM code generator developers: After having read through "The LLVM Target-Independent Code Generator" [1] I'm unclear about what precisely the objects MCInst and MCOperand represent. They sit in the space between assembly syntax and binary encodings, but which are they modeling? For example, a Thumb 2 branch instruction 'b' takes an immediate. That syntax

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

Owen is correct in his descriptions. The MCOperand values are intended to model the instruction encoding. Where that doesn't match the assembly syntax, the asm parser (and codegen) and the instruction printer are responsible for encoding/decoding the values. For targets that predate the MC layer, this isn't always the case, leading to things being a bit confusing when just reading the

An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130220/a080958f/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 201302201044290_44YDXKW4.gif Type: image/gif Size: 14036 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130220/a080958f/attachment.gif>

Dear Mr. Northover, Thank you for the quick reply. You are correct about the address-mode operands :) . I guess an important detail left out was that the basic block (call it A) that wants to calculate the address of the target stationary trampoline basic block (call it B) will be moved around in memory during run-time. Our earlier solution, before the feature was implemented to move around (A)

Hi everyone, The WebAssembly backend recently had Bug 39448 <https://bugs.llvm.org/show_bug.cgi?id=39448> filed against it because NaN payloads in floating-point immediates are not preserved through compilation on 32-bit builds. I took a look and the corruption takes place when the immediates are converted from APFloats to be stored as native doubles in MCOperand. I assume this bug only

On Monday 15 February 2010 14:59:19 Chris Lattner wrote: > On Feb 15, 2010, at 12:53 PM, Chris Lattner wrote: > > On Feb 15, 2010, at 10:00 AM, David Greene wrote: > >> On Monday 15 February 2010 11:54:25 Óscar Fuentes wrote: > >>> David Greene <dag at cray.com> writes: > >>>> Sorry, I botched a commit and broke the build. I've just committed

On Feb 15, 2010, at 12:53 PM, Chris Lattner wrote: > > On Feb 15, 2010, at 10:00 AM, David Greene wrote: > >> On Monday 15 February 2010 11:54:25 Óscar Fuentes wrote: >>> David Greene <dag at cray.com> writes: >>>> Sorry, I botched a commit and broke the build. I've just committed a >>>> fix. >>>> >>>> So expect

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 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();