similar to: Using BuildMI to insert Intel MPX instruction BNDCU failed

On Wed, 2018-02-07 at 21:55 +0000, David Woodhouse via llvm-dev wrote: > Can you take care of filing the tickets for %V0 and "=q" > and attribute__((indirect_branch("keep"))) please? With those fixed, I > think we should be OK again. Here's %V0 support, which makes the hypervisor guest support build. diff --git a/lib/Target/X86/X86AsmPrinter.cpp

On 06/22/2010 11:11 AM, Patrick Marlier wrote: > On 06/21/2010 08:21 PM, Eric Christopher wrote: >> On Jun 21, 2010, at 2:56 AM, Patrick Marlier wrote: >> >> >>> Hello, >>> >>> This bug affects all LLVM versions from 2.6 to trunk : >>> http://llvm.org/bugs/show_bug.cgi?id=5081 >>> >>> The workaround I found is to

On Jul 7, 2010, at 4:52 AM, Patrick Marlier wrote: > Which one is correct ? > - movl $tm_nest_level at TPOFF, %ecx > or > - movq $tm_nest_level at TPOFF, %rcx > or > - movl tm_nest_level at TPOFF, %ecx > I believe this is initial exec and so from: http://people.redhat.com/drepper/tls.pdf it would be movl tm_nest_level at TPOFF, %ecx > Otherwise, Is there a

This should go to llvm-commits as a proper review. Do you want to do that David? Want someone on our end to pick it up? On Wed, Feb 7, 2018 at 3:27 PM David Woodhouse <dwmw2 at infradead.org> wrote: > On Wed, 2018-02-07 at 21:55 +0000, David Woodhouse via llvm-dev wrote: > > Can you take care of filing the tickets for %V0 and "=q" > > and

Hello everyone, I'm working on a MachineFunctionPass that inserts a list of instructions into an Module so a later Pass can work on them. To do so I load a dummy .ll file created from a main stub, create the needed function stubs (ModulePass), insert Blocks and create instructions using BuildMI. I started with branch instructions:     const TargetMachine &TM = MF.getTarget();

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())

I'll save you a review iteration. This is updated to match llvm coding style. Capital camel case variable names and uses LLVM_FALLTHROUGH instead of the comment. static bool printAsmMRegister(X86AsmPrinter &P, const MachineOperand &MO, char Mode, raw_ostream &O) { unsigned Reg = MO.getReg(); + bool EmitPercent = true; + switch (Mode) {

On Wed, 2018-02-07 at 13:16 -0800, Guenter Roeck wrote: > Here are my exact versions: >     llvm: 3afd566557f3 ("AMDGPU: Add 32-bit constant address space") >     clang: 848874aed95a ("[clang-format] Fix ObjC message arguments formatting.") OK, mine are slightly newer than that now, but I now get a working 64- bit defconfig build. It'll still break with any PV

On 06/21/2010 08:21 PM, Eric Christopher wrote: > On Jun 21, 2010, at 2:56 AM, Patrick Marlier wrote: > > >> Hello, >> >> This bug affects all LLVM versions from 2.6 to trunk : >> http://llvm.org/bugs/show_bug.cgi?id=5081 >> >> The workaround I found is to add this : >> >> Index: lib/Target/X86/X86Instr64bit.td >>

On Wed, 2018-02-07 at 23:30 +0000, Chandler Carruth wrote: > This should go to llvm-commits as a proper review. Do you want to do > that David? Want someone on our end to pick it up? I'll attempt to add some test cases... -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5213 bytes Desc: not available

On 03/22/2018 09:29 AM, Julius Hiller via llvm-dev wrote: > Hello everyone, > > I'm working on a MachineFunctionPass that inserts a list of instructions into an Module so a later Pass can work on them. > To do so I load a dummy .ll file created from a main stub, create the needed function stubs (ModulePass), insert Blocks and create instructions using BuildMI. > I started with

Thank you for your help Tom you are totally right with the registers but the command you suggest also doesn't work. After some research I found the following thread on the mailing list: http://lists.llvm.org/pipermail/llvm-dev/2017-February/110086.html With your help and the information about the condition codes I was able to resolve the error:         BuildMI(BB, BB.end(), DL,

On Oct 28, 2013, at 2:02 PM, Tyler Hardin <tghardin1 at catamount.wcu.edu> wrote: > See the source here: https://github.com/earl/llvm-mirror/blob/master/lib/Target/X86/InstPrinter/X86IntelInstPrinter.cpp. It looks like getRegisterName might do what you want, but I don't know where it's coming from. (Whether it's a function or a member of a super class. Hopefully, if it's

On Wed, Feb 07, 2018 at 08:44:32PM +0000, David Woodhouse wrote: > On Wed, 2018-02-07 at 10:11 -0800, Guenter Roeck wrote: > > > On Wed, Feb 07, 2018 at 10:49:25AM +0000, David Woodhouse wrote: > > > Hm, please could we also have the %V asm constraint modifier? That > > > allows us to emit calls to the thunks from inline asm using the > > > register that the

Hi, All, I try to crosee compile 3.0.7 for mips, but failed and got the following message: Configure: error: cannot run test program while cross compiling Can anybody give me a hint about what I did may be wrong? Thanks Youren __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail

On 07/07/2010 08:20 PM, Eric Christopher wrote: > > On Jul 7, 2010, at 4:52 AM, Patrick Marlier wrote: > >> Which one is correct ? >> - movl $tm_nest_level at TPOFF, %ecx >> or >> - movq $tm_nest_level at TPOFF, %rcx >> or >> - movl tm_nest_level at TPOFF, %ecx >> > > I believe this is initial exec and so from: > >

This shouldn't have parsed. movq (%gs), %r14 That's trying to use%gs as a base register which isn't valid. GNU assembler rejects it. And coincidentally llvm-mc started rejecting it on trunk late last week. That's probably why it printed as %ebp. I don't know if there is an instruction to read the base of %gs directly. Maybe rdgsbase, but that's only available on Ivy

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

On Tue, Sep 10, 2013 at 1:19 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk > wrote: > On 10 Sep 2013, at 10:13, Kostya Serebryany <kcc at google.com> wrote: > > > How did you come with 320 bits? > > 320=64*4+64, which is the size of the metadata table entry plus pointer > size, > > > Sorry, that should have been 192. The specification allows the

On 10 Sep 2013, at 10:28, Kostya Serebryany <kcc at google.com> wrote: > > > > On Tue, Sep 10, 2013 at 1:19 PM, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote: > On 10 Sep 2013, at 10:13, Kostya Serebryany <kcc at google.com> wrote: > > > How did you come with 320 bits? > > 320=64*4+64, which is the size of the metadata table entry plus