search for: x86mcinstlow

> 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 register allocat...

...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()) { default: llvm_unreachable("Invalid opcode"); case X86::P_256B_LOAD_DWORD: NewOpc = X86::P_256B_LOAD_DWORD; break; case X86::P_256B_STORE_DWORD: NewOpc = X86::P_256B_STORE_DWORD; break; case X86::P_256B...

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

...ace)::MCAsmStreamer::EmitInstruction(llvm::MCInst const&, llvm::MCSubtargetInfo const&, bool) /home/shenyouren/workspace/llvm/lib/MC/MCAsmStreamer.cpp:1752:0 #16 0x0000000002355fdf llvm::X86AsmPrinter::EmitAndCountInstruction(llvm::MCInst&) /home/shenyouren/workspace/llvm/lib/Target/X86/X86MCInstLower.cpp:107:0 #17 0x0000000002360ae9 llvm::X86AsmPrinter::EmitInstruction(llvm::MachineInstr const*) /home/shenyouren/workspace/llvm/lib/Target/X86/X86MCInstLower.cpp:2604:0 #18 0x000000000292e629 llvm::AsmPrinter::EmitFunctionBody() /home/shenyouren/workspace/llvm/lib/CodeGen/AsmPrinter/AsmPrinter.c...

...erminator, and can only appear at the end of a basic block. 2. The CALL and RET instructions must be adjacent. The best way to handle this is to create a pseudo-instruction representing the call+ret pair. Since the two instructions must stay together, it should be expanded late: In lib/Target/X86/X86MCInstLower.cpp. /jakob

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 create basic blocks, like CMOV and atomics. > > 2. ExpandPostRAPseudos.cpp - For instructi...

...gt; 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 for PATCHABLE_RET in include/... and lib/... then that should give you a better idea of how this works. :) Cheers -- Dean

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

...e's enough isa support for your target in the mips backend as well. There are definitely plenty of things in that target to work on while the rest of the JIT is coming up around. A good start point, as Eric said, would be to add the MC support for the mips backend, see X86MCCodeEmitter.cpp and X86MCInstLower.cpp for a more concrete example of how it can be done. -- Bruno Cardoso Lopes http://www.brunocardoso.cc

...t 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 X86AsmPrinter::EmitXRayTable() { if (Sleds.empty()) return; if (Subtarget->isTargetELF()) { auto *Section = OutContext.getELFSection( "xray_instr_map", ELF::SHT_PROGBITS, ELF::SHF_ALLOC | ELF::SHF_GROUP | ELF::SHF_MERGE, 0, CurrentFnSym...

...alar/PlaceSafepoints.cpp#L441 [rewritestatepoints] https://github.com/llvm-mirror/llvm/blob/a40ba754c3f765768d441b9b4b534da917f8ad3c/lib/Transforms/Scalar/RewriteStatepointsForGC.cpp#L2286 [backend-x64] https://github.com/llvm-mirror/llvm/blob/a40ba754c3f765768d441b9b4b534da917f8ad3c/lib/Target/X86/X86MCInstLower.cpp#L841 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160303/818cb257/attachment.html>

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

...ges: test.s:43: Warning: stand-alone `data16' prefix I just wonder why I have data16 instruction in my assembly file. (ps. If I build it with "llc test.ll", the assembly file will not have data16 instruction) I search the llvm project and find some clues in this file: lib/Target/X86/X86MCInstLower.cpp static void LowerTlsAddr(...) { bool is64Bits = MI.getOpcode() == X86::TLS_addr64; .... if (is64Bits) { MCInst prefix; prefix.setOpcode(X86::DATA16_PREFIX); .... } .... } I think it is the logic to generate data16 instruction, but I wonder why gcc...

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

...one `data16' prefix > > I just wonder why I have data16 instruction in my assembly file. > (ps. If I build it with "llc test.ll", the assembly file will not have > data16 instruction) > > I search the llvm project and find some clues in this > file: lib/Target/X86/X86MCInstLower.cpp > static void LowerTlsAddr(...) > { > bool is64Bits = MI.getOpcode() == X86::TLS_addr64; > .... > if (is64Bits) { > MCInst prefix; > prefix.setOpcode(X86::DATA16_PREFIX); > .... > } > .... > } > > I think it is...

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