Displaying 4 results from an estimated 4 matches for "rhsidx".
Did you mean:
lhsidx
2012 Jul 09
2
[LLVMdev] question on table gen TIED_TO constraint
...y operand.
See the section about MRMSrcMem in RecognizableInstr::emitInstructionSpecifier.
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
2012 Jul 10
0
[LLVMdev] question on table gen TIED_TO constraint
...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/mailm...
2012 Jul 10
2
[LLVMdev] question on table gen TIED_TO constraint
...nSpecifier.
>
> 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
>...
2012 Jul 10
0
[LLVMdev] question on table gen TIED_TO constraint
...xed?
> >
> > 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....