similar to: Problem with inserting a function call after certain x86 instructions

I have a MachineFunctionPass plugged into llc during LLVMTargetMachine::addPreRegAlloc. In this Pass I need to extend calls (i. e. CALL32m, CALL32r) iff they call function within the program. CALL32m has, I think, ten different possibilities for the four operands giving the target address. At the moment I have excluded calls that give the displacement as GlobalAddress or JumpTableIndex

Hi all, I am really stumped on a problem for long. I could not figure out why. That is why i am here. OK, here is the problem: I tried to insert a MachineBasicBlock into a function. Here is the code snippet: // insert a machine basic block with the error_label into MF and before I // Pred is the predecessor of the block to be inserted // the new basic block is inserted right before I void

Hi all, I am still stumped on the same bug. Did anyone try to insert MachineBasicBlock into a MachineFunction? Any advice will be appreciated. Thanks a lot in advance. ~Bin ---------------------------------------------------------------------------------------------------------------------------- Thanks a lot Jeff. I changed the setNumber function call to

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

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

Comments below. On Apr 15, 2008, at 4:24 AM, Nicolas Geoffray wrote: > 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. >

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,

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

Also, please elaborate on why this is a good change. Because gas accepts it isn’t sufficient reason in and of itself. -Jim On Jul 10, 2013, at 1:18 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > 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

Hi, This patch fixes outs/ins of MOV16mr instruction of X86. Thanks. diff --git a/lib/Target/X86/X86InstrInfo.td b/lib/Target/X86/X86InstrInfo.td index e9a0431..f5b2064 100644 --- a/lib/Target/X86/X86InstrInfo.td +++ b/lib/Target/X86/X86InstrInfo.td @@ -1412,7 +1412,7 @@ let SchedRW = [WriteStore] in { def MOV8mr : I<0x88, MRMDestMem, (outs), (ins i8mem :$dst, GR8 :$src),

Hi, I would like to query the X86InstrInfo tables to determine if a given opcode is a load or store from stack. I see functions isFrameLoadOpcode and isFrameStoreOpcode in lib/Target/X86/X86InstrInfo.cpp that would provide the functionality I am looking for. However, these functions are static. What is the recommended way to perform such queries for a MachineInstr - short of replicating the

Just for informational purposes on a smaller system (Core 2 Duo MacBook Pro): make none X86.td X86InstrInfo.cpp real 11.568 217% 76.283 177% 34.435 169% user 7.726 141% 70.659 100% 25.608 116% sys 3.234 111% 3.992 100% 6.438 104% make -j2 none X86.td X86InstrInfo.cpp real 7.7346 145% 43.138 100% 25.77 127% user 7.6072 139% 70.414 100% 26.589 121% sys 3.2492 111% 3.984 100%

Hi all, as soon as I try to split MachineBasicBlocks the resulting programs suffer from segmentation faults. I have reproduced the error using a simple MachineFunctionPass in the X86 backend that splits MachineBasicBlocks before CALL32m instructions (and inserts a fallthrough-jmp). The MachineFunctionPass is plugged into X86TargetMachine::addPreRegAlloc. The split-method is basically stolen from

Hey edA-qa mort-ora-y, On Sat, Nov 9, 2013 at 6:47 AM, edA-qa mort-ora-y <eda-qa at disemia.com> wrote: > I'm getting an error that I don't know how to fix. I've isolated the > input as much as I easily can. I've attached the file that produces the > problem. Just calling "llc err.ll -o err.s" generates the error. > > I'm going to try and isolate

Hi, I had (naively?) expected that the instruction to move immediate to register or memory (such as MOV32mi, MOV32ri, MOV64mi32, MOV64ri, MOV64ri32) would be marked with the flag MCID::MovImm via the X86InstrInfo.td (and hence in the generated X86GenInstrInfo.inc). I do not see that to be the case. Can someone please tell me if my expectation is flawed? Is there a better/different way to

Hello, Here is one question regarding the LLVM TableGen: Which file in the llvm/lib/Target/X86 folder describes how the bits in the EFLAGS register are modified by the x86 instructions? For example, in the "X86InstrInfo.td" file, lines 2134-2135, it says: let SchedRW = [WriteALU], Defs = [EFLAGS], Uses = [EFLAGS] in { def CLC : I<0xF8, RawFrm, (outs), (ins), "clc",

That flag is specifically used by the foldImmediate optimization in the Peephole pass. We don't implement the TLI foldImmediate hook the peephole pass uses on x86 so we have no reason to set the flag on any instructions What are you trying to do? ~Craig On Fri, Feb 9, 2018 at 11:45 AM, S. Bharadwaj Yadavalli via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > I had

Some problems... (or I'm missing something...) 1) asmwriternum seems to be not supported... scons: Building targets ... d:/home/arathorn/sandbox/llvm/tblgen.exe -gen-asm-writer -asmwriternum=1 -I llvm\lib\Target\X86 -o tablegen_includes\X86GenIntelAsmWriter.inc llvm\lib\Target\X86\X86.td llvm\lib\Target\X86\X86InstrInfo.td llvm\lib\Target\X86\X86RegisterInfo.td llvm\lib\Target\Target.td

One place to look might be in the MachineOutliner target hooks in X86InstrInfo and AArch64InstrInfo. The MachineOutliner runs extremely late in the pass pipeline so it might be a good place to look for some inspiration. Of course, because this is *extremely late* it might not do *exactly* what you need. (e.g, this is post-register allocation, post frame-lowering, etc.) - Jessica > On May 4,