similar to: Can I differentiate an imm with an imm used in memory offset in MI pass?

The generic code in lib/CodeGen has no knowledge of these semantic differences. This knowledge is only available on a per-target basis. Typical query functions would be X86InstrInfo::getMemOpBaseRegImmOfs(...) or AArch64::getMemOpInfo(...). Doing this in a common way accross targets requires callbacks in TargetInstrInfo, there seem to be some in that direction but they appear to be rarely used so

OK, here's a new patch that adds the infrastructure and the implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize. Both functions are virtual functions defined in TargetInstrInfo.h. For X86, I moved some commodity functions from X86CodeEmitter to X86InstrInfo. What do you think? Nicolas Evan Cheng wrote: > > I think both of these belong to TargetInstrInfo. And

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

On Wed, Jul 10, 2013 at 12:29 PM, Ramkumar Ramachandra <artagnon at gmail.com> wrote: > The instructions btr and bts are perfectly valid, and have existed since > Intel 386. GNU as supports them fine. Unfortunately, LLVM does not > support them, and barfs with: > > error: ambiguous instructions require an explicit suffix > > Fix this problem by disambiguating it

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, For the following test-case: void foo(unsigned, unsigned); void f() { foo(10, 20); foo(10, 20); } clang --target=arm-linux-gnueabi -mthumb -O2 generates: push {r4, r5, r7, lr} movs r4, #10 movs r5, #20 movs r0, r4 movs r1, r5 bl foo movs r0, r4 movs r1, r5 bl foo pop {r4,

Hi Evan, Evan Cheng wrote: > > Yeah, sorry I'm stubborn sometimes. :-) And really I think adding the > code size functionality is not really that complicated. I would be > happy to help if you run into issues. > > What do you think of adding a TargetMachine::getFunctionSize(MachineFunction*) and a TargetInstrInfo::getInstructionSize(MachineInstruction*)? Is this a

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

There can also be other “problems" like this one: http://reviews.llvm.org/D6946 <http://reviews.llvm.org/D6946> - Matthias > On Apr 20, 2015, at 1:44 PM, Tim Northover <t.p.northover at gmail.com> wrote: > >> The DAG combiner also performs the undefined shift -> undef though, so it >> should still be OK > > DAG combiner doesn't really run to

Hello all, Is there an easy way to get the human-readable opcode mnemonic (e.g., "MOV32ri64", "CMP32ri8", "JLE_1") for a MachineInstr? I am writing a backend analysis pass for security research, where the idea is for a researcher to examine the output of my pass and identify instructions from it for use in an attack. Right now I'm representing unique

On Apr 14, 2008, at 6:07 AM, Nicolas Geoffray wrote: > Hi Evan, > > Evan Cheng wrote: >> >> Yeah, sorry I'm stubborn sometimes. :-) And really I think adding the >> code size functionality is not really that complicated. I would be >> happy to help if you run into issues. >> >> > > What do you think of adding a >

Hi, All, I want to add one intrinsic function for my particular backend. Let's say the intrinsic function is named "foo" which takes two i32 inputs and has one i32 output. First, I add this line "def int_foo : Intrinsic<[llvm_i32_ty], [llvm_i32_ty, llvm_i32_ty], [IntrReadArgMem]>;" in /include/llvm/IR/Intrinsics.td. Then, in my target/InstrInfo.td, I'm supposed

Add emission rules for negative and saturate flags for MAD 4-byte opcodes, and get rid of constraints. Short MAD has a very specific SDST == SSRC2 requirement, and since MAD IMM is short notation + 4-byte immediate, don't have the compiler create MAD IMM instructions yet. V2: Document MAD as supported short form Signed-off-by: Roy Spliet <rspliet at eclipso.eu> ---

Hi When I run a program I've written with Delphi7, I get several of the following messages: fixme:imm:ImmReleaseContext (0x10020, 0x403b9e80): stub . . . The program works - but is there anything I can do to avoid these messages? Rainer -- Rainer M. Krug, Dipl. Phys. (Germany), MSc Conservation Biology (UCT) Department of Conservation Ecology and Entomology University of Stellenbosch

I have some code such that: vgpr1 = mov 0 branch bb bb: PHI vgpr2 = vgpr1, …. PHI vgpr3 = vgpr1, …. PHI vgpr4 = vgpr1, …. PHI vgpr5 = vgpr1, …. PHI node elimination is generating copies for all these PHIs (and hoisting them) as such: vgpr1 = 0 vgpr20 = COPY vgpr1 // old vgpr2 vgpr30 = COPY vgpr1 // old vgpr3 vgpr40 = COPY vgpr1 // old vgpr4 vgpr 50 = COPY vgprt1 // old vgpr5 I expect the zero

Ok, this makes sense. So, my follow up is then why, as in Mips, R600, etc... the bit value is checked in the tablegen. Seems that we should expect it to fit anyways if it still exists at this point? I'm having a hard time trying to get shl to take a PatLeaf for Imm instead of an ImmLeaf. On Mon, Apr 20, 2015 at 4:11 PM, David Majnemer <david.majnemer at gmail.com> wrote: > >

In this case the load imm is foldable into the copy, once converted to a mov. Directly folding this would be 4 v_mov_b32 instead of 5 produced currently -Matt On 11/14/19, 07:20, "llvm-dev on behalf of Quentin Colombet via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> wrote: Hi Ryan, Unless you can fold your immediate

This would require getting the reaching definition which requires live intervals analysis. On Thu, Nov 14, 2019 at 12:15 PM Quentin Colombet <qcolombet at apple.com> wrote: > That sounds like the folding could be done when you expand the copy in > expand pseudo after regalloc. > > > On Nov 14, 2019, at 12:20 AM, Arsenault, Matthew < > Matthew.Arsenault at amd.com>

in llvm-3.6.2.src 1. when I put this around one of my instruction definitions in my target "InstrInfo.td" file, let TwoOperandAliasConstraint = "$dst = $rs1" in { } I do not see any TIED_TO in the generated GenInstrInfo.inc file for the OperandInfo used by the instruction, the question is what am I doing wrong ? 2. I've noticed that TwoOperandAliasConstraint