search for: mcoperand

...$4)                                       ^ Compare with Loongson GCC toolchain: .text gs:     .set    noat     gslble    $2, $3, $4              # encoding: [0x10,0x20,0x62,0xc8]                                         # <MCInst #1546 GSLBLE                                         #  <MCOperand Reg:321>                                         #  <MCOperand Reg:322>                                         #  <MCOperand Reg:22>>     gslbgt    $5, $6, $7              # encoding: [0x11,0x38,0xc5,0xc8]                                         # <MCInst #1545 GSLBGT    ...

...bly as close as you can get. $ clang -S -O0 test.c -mllvm -show-mc-inst -o - _test: ## @test .cfi_startproc ## BB#0: ## %entry pushq %rbp ## <MCInst #2120 PUSH64r ## <MCOperand Reg:106>> Ltmp2: .cfi_def_cfa_offset 16 Ltmp3: .cfi_offset %rbp, -16 movq %rsp, %rbp ## <MCInst #1491 MOV64rr ## <MCOperand Reg:106> ## <MCOperand Reg:114>> Ltmp4: .cfi_def_cfa...

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 "b #1234" can map to a couple different encodings. If it is an even number between -2048 an...

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

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

...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 <MCOperand Reg:105> <-- maps to reg sp <MCOperand Imm:8> <-- maps to immed #8 <MCOperand Imm:14> <MCOperand Reg:0> Now, what are the two last operands (that are not actually present in disassembly)? And is it someho...

...-S -O0 test.c -mllvm -show-mc-inst -o - > _test:                                  ## @test >        .cfi_startproc > ## BB#0:                                ## %entry >        pushq   %rbp                    ## <MCInst #2120 PUSH64r >                                        ##  <MCOperand Reg:106>> > Ltmp2: >        .cfi_def_cfa_offset 16 > Ltmp3: >        .cfi_offset %rbp, -16 >        movq    %rsp, %rbp              ## <MCInst #1491 MOV64rr >                                        ##  <MCOperand Reg:106> >                                        ...

...ue in R15 into R14:(%GS) [ (%GS) + > R14 ] > > -------------------------------------------------------------------------------------------------- > LLVM-MC -show inst gives: > movq (%gs), %r14 # <MCInst #1810 MOV64rm > # <MCOperand Reg:117> > # <MCOperand Reg:33> > # <MCOperand Imm:1> > # <MCOperand Reg:0> > # <MCOperand Imm:0&gt...

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)

...t;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 appears in 32-bit builds because they are using x87 doubles that happen to not preserve all possible NaN payloads. There are two things we could do here: Change MCOperand to not store floating point immediates as native doubles, or explicitly accept that NaN payloads in imm...

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 >= 0) O << '+'; O << Imm; } else { assert(Op.isExpr() && "unknown pcrel im...

...B.end(), DL, TII->get(ARM::B)).addMBB(trgBlock); these are working fine. When creating an compare instruction like cmp r0, 1 with:      BuildMI(BB, BB.end(), DL, TII->get(ARM::tCMPi8),0).addImm(1); I get the following error:     .../include/llvm/MC/MCInst.h:81: int64_t llvm::MCOperand::getImm() const: Assertion `isImm() && "This is not an immediate"' failed. Which even after hours I can't make sense why the operand kind is wrong. Another thing I noticed is that using ARM::tB results in the following error: .../include/llvm/ADT/SmallVector.h:...

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

...s like "$0" into physical register names), it 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 inl...

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

...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 <MCOperand Reg:105> <-- maps to reg sp <MCOperand Imm:8> <-- maps to immed #8 <MCOperand Imm:14> <MCOperand Reg:0> Now, what are the two last operands (that are not actually present in disassembly)? And is it someho...

...B(trgBlock); > > these are working fine. > When creating an compare instruction like cmp r0, 1 with: > > BuildMI(BB, BB.end(), DL, TII->get(ARM::tCMPi8),0).addImm(1); > > I get the following error: > > .../include/llvm/MC/MCInst.h:81: int64_t llvm::MCOperand::getImm() const: Assertion `isImm() && "This is not an immediate"' failed. > According to ARMInstrThumb.td, tCMPi8's source arguments are reg, imm and there is no explicit destination register, so what you want is: BuildMI(BB, BB.end(), DL, TII->get(ARM::tCMPi8))....