[llvm-dev] New register class and patterns
Rail Shafigulin via llvm-dev
llvm-dev at lists.llvm.org
Wed Feb 3 18:17:00 PST 2016
>
>
>
>
> def SDTX86CmpPTest : SDTypeProfile<1, 2, [SDTCisVT<0, i32>,
> SDTCisVec<1>,
> SDTCisSameAs<2, 1>]>;
>
> This is confusing to me. This tells me that there is 1 result but and 2
> operands. But then it says that operands 2 and 1 are of the same type,
> SDTCisSameAs<2, 1>. Given that operand numbering starts at 0, how can there
> be operands 2 and 1?
>
>
> The results are numbered starting from 0. In this case with 1 result, 0 is
> the output operand, and 1 and 2 are the inputs.
>
>
>
> Based on the previous answer my understanding is that LLVM is complaining
> because it doesn't know what register to use. What is unclear to me is why?
> I already had 2 register classes before and everything was working. All
> I've done is that I had added an extra class. After that LLVM started to
> complain. And this is what puzzles me.
>
> Did you add a register class for a special condition register? Did you set
> it as isAllocatable = 0?
>
I think I'm slowly getting it. To answer your question, no I did not set
isAllocaable = 0 for the new register class. But I'm still confused.
Original instruction does not have an output register. It sets a flag in
the special purpose register. So why creating a new register class would
cause a problem? In other words, since there is no output register, why
would LLVM start complaining. Below I'm repeating some code for reference.
Any help is appreciated.
def SDT_EscalaSetFlag : SDTypeProfile<0, 3, [SDTCisSameAs<0, 1>]>;
def Esenciasetflag : SDNode<"EsenciaISD::SET_FLAG", SDT_EsenciaSetFlag,
[SDNPOutGlue]>;
class SF_RI<bits<5> op2Val, string asmstr, PatLeaf Cond>
: InstRI<0xf, (outs), (ins GPR:$rA, s16imm:$imm),
!strconcat(asmstr, "i\t$rA, $imm"),
[(Escalasetflag (i32 GPR:$rA), immSExt16:$imm, Cond)]> {
bits<5> op2;
bits<5> rA;
bits<16> imm;
let Inst{25-21} = op2;
let Inst{20-16} = rA;
let Inst{15-0} = imm;
let format = AFrm;
let op2 = op2Val;
}
--
Rail Shafigulin
Software Engineer
Esencia Technologies
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160203/4737a908/attachment.html>
More information about the llvm-dev
mailing list