search for: x86mcinstlowering

> it should be expanded late: In lib/Target/X86/X86MCInstLower.cpp. This is exactly what I was missing. Thanks a ton! :) -- Sanjoy Das http://playingwithpointers.com

On Oct 18, 2011, at 2:33 PM, Sanjoy Das wrote: >> it should be expanded late: In lib/Target/X86/X86MCInstLower.cpp. > > This is exactly what I was missing. Thanks a ton! :) We have three pseudo expansion passes: 1. ExpandISelPseudos.cpp - For instructions that may need to create basic blocks, like CMOV and atomics. 2. ExpandPostRAPseudos.cpp - For instructions used to trick the

i want to emit binary code for the following implemented vector assembly instructions. P_256B_LOAD_DWORD R_0_R2048b_0, pword ptr [rip + b] P_256B_LOAD_DWORD R_0_R2048b_1, pword ptr [rip + c] P_256B_VADD R_0_R2048b_0, R_0_R2048b_1, R_0_R2048b_0 P_256B_STORE_DWORD pword ptr [rip + a], R_0_R2048b_0 I added the following lines in X86MCInstLower.cpp; unsigned NewOpc; switch (OutMI.getOpcode())

Hello everyone, In the file *lib/CodeGen/AsmPrinter/AsmPrinter.cpp*, I would like to obtain an MCInst corresponding to its MachineInstr. Can anyone tell me a way to do that? If that is not possible, then, I would like to know if a given MachineInstr is an *lea *instruction and I would like to know if the symbol involved with this lea instruction is a jump-table. For instance, given a

Hello everyone, I'm a newbie of llvm. I'm trying to insert Intel MPX instruction BNDCU with BuildMI. I add my machinefunctionpass at addPreEmitPass2. Here is the code of insertion: BuildMI(MBB, MI, DL, TII->get(X86::BNDCU64rr)).addReg(X86::BND2, RegState::Define).addReg(X86::R10); And here is to stack track when I compiler program with modified llc:

On Oct 18, 2011, at 2:02 PM, Sanjoy Das wrote: > This about fixing the issue with having a the BB ending with a > non-terminating instruction when compiling with segmented stacks. I'm > not sure if having an isel pseudo instruction which is lowered into a > RET and then a MOV would work better. > LLVMTargetMachine::addCommonCodeGenPasses adds the > ExpandISelPseudosPass

On Oct 18, 2011, at 2:46 PM, Jakob Stoklund Olesen wrote: > > On Oct 18, 2011, at 2:33 PM, Sanjoy Das wrote: > >>> it should be expanded late: In lib/Target/X86/X86MCInstLower.cpp. >> >> This is exactly what I was missing. Thanks a ton! :) > > We have three pseudo expansion passes: > > 1. ExpandISelPseudos.cpp - For instructions that may need to

> On 5 Sep 2016, at 16:14, SHUCAI YAO <yaos4 at mcmaster.ca> wrote: > > > Hi Dean, > > Do you have any example for this? I would like have a look at how you handle this in XRay if it is possible. > Yes, this is all upstream -- if you look in lib/CodeGen/XRayInstrument.cpp and the associated lowering code for X86 in lib/Target/X86/X86MCInstLower.cpp and/or search

Hi! First of all, sorry for the delay. This about fixing the issue with having a the BB ending with a non-terminating instruction when compiling with segmented stacks. I'm not sure if having an isel pseudo instruction which is lowered into a RET and then a MOV would work better. LLVMTargetMachine::addCommonCodeGenPasses adds the ExpandISelPseudosPass before the PEI pass (so it boils down to

On Wed, Nov 17, 2010 at 6:45 AM, Eric Christopher <echristo at apple.com> wrote: > > On Nov 17, 2010, at 12:37 AM, Michael.Kang wrote: > >> On Wed, Nov 17, 2010 at 4:30 PM, James Molloy <James.Molloy at arm.com> wrote: >>> Hi, >>> >>> There are numerous emails flying around the list at the moment regarding the state of the JIT. In its current

Hi Dean, I have a question for 32-bit platforms. I see in the code that you used the following in compiler-rt/trunk/lib/xray/xray_interface_internal.h : struct XRaySledEntry { uint64_t Address; uint64_t Function; unsigned char Kind; unsigned char AlwaysInstrument; unsigned char Padding[14]; // Need 32 bytes }; And the peer code in llvm/trunk/lib/Target/X86/X86MCInstLower.cpp : void

Hello LLVM community, We have been experimenting with using LLVM IR as a target for a managed (dynamically typed) language via an AOT compiler (including a backend for ARM). One main challenge is getting the garbage collection right: We would like to be able to implement a moving collector. This requires us to a) find a precise set of root pointers and b) be able to rewrite those pointers after

...e not to bother with if I don't have to. Current implementation details We have support in the integrated assembler only for autopadding suppression.  This allows a LLVM based compiler to effectively apply padding selectively.  In particular, we've instrumented lowering from MI to MC (X86MCInstLowering.cpp) to selectively disable padding around constructs which are thought to be problematic.  We do not have an agreed upon syntax for this in assembler; the code that got checked in is modeled closely around the last seriously discussed variant (see below).  This support is able to use all of th...

Hi all, System: x86-64 ubuntu 11.04 LLVM: 3.0 gcc: 4.5.2 I declare a thread_local global variable and access it in a function in llvm IR. for example, @my_value = linkonce thread_local global %dummy* null define void @test1() { entry: %load_my_value = load %dummy** @my_value .... } After that, I use the following command: bash$ llc -relocation-model=pic test.ll And I have test.s

> On 5 Sep 2016, at 11:49, SHUCAI YAO <yaos4 at mcmaster.ca> wrote: > > For the function call lowering, do you mean lowercall function? I did insert the instruction before the stack adjustments, but the inserted code appears in the prologue of the function, other than before the function call. Maybe I did something wrong with the iterator. > > So you mean I should insert a

On Nov 17, 2010, at 12:37 AM, Michael.Kang wrote: > On Wed, Nov 17, 2010 at 4:30 PM, James Molloy <James.Molloy at arm.com> wrote: >> Hi, >> >> There are numerous emails flying around the list at the moment regarding the state of the JIT. In its current state it is infeasible to add support for another architecture (very difficult to say the least) - there are plans

Hi, I'm writting an intrinsics for the X86 plateform that replace every 'call' instruction by a 'push ret_addr' followed by a 'jmp func_addr'. I'm doing this in the X86ISelLowering class with a custom inserter. So if I have something like this: 0x0 call foobar 0x1 ... the call will be replaced like this: 0x0 push 0x2 0x1 jmp foobar_addr 0x2 ... This works fine

...e to. > > > > Current implementation details > > We have support in the integrated assembler only for autopadding > suppression. This allows a LLVM based compiler to effectively apply > padding selectively. In particular, we've instrumented lowering from MI to > MC (X86MCInstLowering.cpp) to selectively disable padding around constructs > which are thought to be problematic. We do not have an agreed upon syntax > for this in assembler; the code that got checked in is modeled closely > around the last seriously discussed variant (see below). This support is > able...

Hey Cameron, Sorry to reply this mail so late. Recently, I tried to understand what's the impact of the warning message (Warning: stand-alone `data16' prefix) And in binutils (gas/config/tc-i386.c), I found: if (!quiet_warnings) { ..... if (t->opcode_modifier.isprefix && t->opcode_modifier.ignoresize) { /* Warn them that a data or address

On Wed, Nov 17, 2010 at 4:30 PM, James Molloy <James.Molloy at arm.com> wrote: > Hi, > > There are numerous emails flying around the list at the moment regarding the state of the JIT. In its current state it is infeasible to add support for another architecture (very difficult to say the least) - there are plans currently being formulated to deal with this and convert the JIT to the