[LLVMdev] question on table gen TIED_TO constraint

[Craig Topper]

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 VEX_4VOp3 is true and
> assumes register, vvvv register, memory if VEX_4V is true.
>
> I just need to change the flag from VEX_4VOp3 to VEX_4V. There are a few
> places where we assume only the 2nd operand can be tied-to:
> Desc->getOperandConstraint(1, MCOI::TIED_TO) != -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, $mask = $mask_wb" in {
> >> ...
> >> def rm  : AVX28I<opc, MRMSrcMem, (outs VR128:$dst, VR128:$mask_wb),
> >>           (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, $mask_wb, $src1, $mem, $mask, and $mask_wb
> is the second physical operand.
> >>
> >> I thought about using "$mask_wb = $mask", but it breaks the assumption
> of TIED_TO 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>