[LLVMdev] question on table gen TIED_TO constraint (original) (raw)

Craig Topper craig.topper at gmail.com
Mon Jul 9 23:47:59 PDT 2012

I don't think changing to VEX_4VOp3 to VEX_4V is the right fix. I think the fix is to increment CurOp twice at the start for these instructions so that only the input operands are used for encoding.

Also, I just submitted a patch to revert the operand order for these instructions in the assembler/disassembler. Destination register should appear on the right and the mask should appear on the left as we use AT&T syntax by default. It will probably conflict with your updates here.

On Mon, Jul 9, 2012 at 11:24 PM, Manman Ren <mren at apple.com> wrote:

Yes, there is an easy way to fix this. MRMSrcMem assumes register, memory, vvvv register if VEX4VOp3 is true and assumes register, vvvv register, memory if VEX4V is true. I just need to change the flag from VEX4VOp3 to VEX4V. There are a few places where we assume only the 2nd operand can be tied-to: Desc->getOperandConstraint(1, MCOI::TIEDTO) != -1 (hard-coded index 1) I will fix those to handle this instruction. Thanks, Manman On Jul 9, 2012, at 10:07 PM, Evan Cheng wrote: > > > On Jul 9, 2012, at 4:15 PM, Manman Ren <mren at apple.com> wrote: > >> >> I need to implement an instruction which has 2 read-write registers, so I added >> let Constraints = "$src1 = dst,dst, dst,mask = $maskwb" in { >> ... >> def rm : AVX28I<opc, MRMSrcMem, (outs VR128:$dst, VR128:$maskwb),_ _>> (ins VR128:$src1, v128mem:$src2, VR128:$mask), >> ... >> } >> There is a problem since MRMSrcMem assumes the 2nd physical operand is a memory operand. >> See the section about MRMSrcMem in RecognizableInstr::emitInstructionSpecifier. > > Can this be fixed? > > Evan > >> And the above gives us dst,dst, dst,maskwb, src1,src1, src1,mem, mask,andmask, and mask,andmaskwb is the second physical operand. >> >> I thought about using "$maskwb = $mask", but it breaks the assumption of TIEDTO LhsIdx > RhsIdx. >> Is adding another addressing mode a good idea? >> >> Any pointer is appreciated. >> Thanks, >> Manman _>> ________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-- ~Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120709/2212090d/attachment.html>

More information about the llvm-dev mailing list