search for: mcoperands

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

...encoding, which matches my intuition. There has been some discussion on the llvm-commits list encouraging us to store the encoded value in the MCOperand. The justification, as I understand it, is that the MCOperand should not contain values that cannot be encoded. This effectively means that the MCOperands would be modeling the binary encoding, not the syntax. Are folks making this transition in other backends as well? [1] http://llvm.org/docs/CodeGenerator.html Thanks, Greg

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: double test(long long s) { return s; } gcc -S -dp -O0 test.c test: .LFB0: .cfi_startproc pushq %rbp # 18 *pushdi2_rex64/1 [length = 1] .cfi_def_cfa_offset 16 movq %rsp, %rbp # 19 *movdi_1_rex64/2

...y > intuition. There has been some discussion on the llvm-commits list > encouraging us to store the encoded value in the MCOperand. The > justification, as I understand it, is that the MCOperand should not > contain values that cannot be encoded. This effectively means that > the MCOperands would be modeling the binary encoding, not the syntax. > Are folks making this transition in other backends as well? > > [1] http://llvm.org/docs/CodeGenerator.html > > Thanks, > Greg > _______________________________________________ > LLVM Developers mailing list > LLV...

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

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

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>

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

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

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

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

...records the offset from the start of the (output) string at which each operand expansion appeared. - The table-generated assembly matcher is modified to record the index of the MCParsedAsmOperand which resulted in in the creation of each MCOperand. An MCParsedAsmOperand can create multiple MCOperands (for example, a memory operand with base and offset), but not the other way round, so this information is stored in the MCOperand. - When the AsmParser is running and a tracking object is present (it is only present if we are parsing inline assembly), it records in each ParsedOperand the in...

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

The MCInstrDesc has a method getNumDefs() which tells you how many 'out registers' that MCInst has. The 'out' registers are always at the beginning of the list. You can also use getNumOperands(). Not sure if this is what you are looking for. -----Original Message----- From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Vladimir Pouzanov

On 03/22/2018 09:29 AM, Julius Hiller via llvm-dev wrote: > 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