Displaying 7 results from an estimated 7 matches for "setccvt".
Did you mean:
setcc
2010 Oct 02
1
[LLVMdev] Illegal optimization in LLVM 2.8 during SelectionDAG? (Re: comparison pattern trouble - might be a bug in LLVM 2.8?)
...1&& Op0.hasOneUse()&&
>> Op0.getOpcode() == ISD::XOR) {
>> TheXor = Op0.getNode();
>> Equal = true;
>> }
>>
>> SDValue NodeToReplace = Trunc ? SDValue(Trunc, 0) : N1;
>>
>> EVT SetCCVT = NodeToReplace.getValueType();
>> if (LegalTypes)
>> SetCCVT = TLI.getSetCCResultType(SetCCVT);
>> SDValue SetCC = DAG.getSetCC(TheXor->getDebugLoc(),
>> SetCCVT,
>> Op0,...
2017 Jul 20
3
Issue with DAG legalization of brcond, setcc, xor
...is an xor. Later on, it also sees that the two
operands to the xor are neither setcc, so it converts the xor to setcc
again. I would be fine with this, but when it tries to find the output
type of the setcc, it chooses i32 instead of i1. Again, it seems this
happens from the line of code that is:
SetCCVT = getSetCCResultType(SetCCVT)
All that function does though is return the data type for pointers.
Well, to my questions I guess. Why is this happening? Isn't it kinda
silly to convert a setcc to an xor, and then convert it back to a
slightly different output setcc. And how can I prevent this,...
2010 Sep 30
4
[LLVMdev] Illegal optimization in LLVM 2.8 during SelectionDAG? (Re: comparison pattern trouble - might be a bug in LLVM 2.8?)
...t;ConstantSDNode>(Op0))
if (RHSCI->getAPIntValue() == 1 && Op0.hasOneUse() &&
Op0.getOpcode() == ISD::XOR) {
TheXor = Op0.getNode();
Equal = true;
}
SDValue NodeToReplace = Trunc ? SDValue(Trunc, 0) : N1;
EVT SetCCVT = NodeToReplace.getValueType();
if (LegalTypes)
SetCCVT = TLI.getSetCCResultType(SetCCVT);
SDValue SetCC = DAG.getSetCC(TheXor->getDebugLoc(),
SetCCVT,
Op0, Op1,
Equ...
2010 Oct 01
0
[LLVMdev] Illegal optimization in LLVM 2.8 during SelectionDAG? (Re: comparison pattern trouble - might be a bug in LLVM 2.8?)
...if (RHSCI->getAPIntValue() == 1 && Op0.hasOneUse() &&
> Op0.getOpcode() == ISD::XOR) {
> TheXor = Op0.getNode();
> Equal = true;
> }
>
> SDValue NodeToReplace = Trunc ? SDValue(Trunc, 0) : N1;
>
> EVT SetCCVT = NodeToReplace.getValueType();
> if (LegalTypes)
> SetCCVT = TLI.getSetCCResultType(SetCCVT);
> SDValue SetCC = DAG.getSetCC(TheXor->getDebugLoc(),
> SetCCVT,
> Op0, Op1,
>...
2017 Jul 21
4
Issue with DAG legalization of brcond, setcc, xor
...on, it also sees that the two operands to the xor are neither setcc, so it converts the xor to setcc again. I would be fine with this, but when it tries to find the output type of the setcc, it chooses i32 instead of i1. Again, it seems this happens from the line of code that is:
>>
>> SetCCVT = getSetCCResultType(SetCCVT)
>>
>> All that function does though is return the data type for pointers.
>>
>> Well, to my questions I guess. Why is this happening? Isn't it kinda silly to convert a setcc to an xor, and then convert it back to a slightly different output...
2010 Sep 29
0
[LLVMdev] comparison pattern trouble - might be a bug in LLVM 2.8?
On Sep 29, 2010, at 12:36 AM, Heikki Kultala wrote:
> On 29 Sep 2010, at 06:25, Heikki Kultala wrote:
>
>> Our architecture has 1-bit boolean predicate registers.
>>
>> I've defined comparison
>>
>> def NErrb : InstTCE<(outs I1Regs:$op3), (ins I32Regs:$op1,I32Regs:$op2), "", [(set I1Regs:$op3, (setne I32Regs:$op1, I32Regs:$op2))]>;
2010 Sep 29
1
[LLVMdev] comparison pattern trouble - might be a bug in LLVM 2.8?
On 29 Sep 2010, at 06:25, Heikki Kultala wrote:
> Our architecture has 1-bit boolean predicate registers.
>
> I've defined comparison
>
>
> def NErrb : InstTCE<(outs I1Regs:$op3), (ins I32Regs:$op1,I32Regs:$op2), "", [(set I1Regs:$op3, (setne I32Regs:$op1, I32Regs:$op2))]>;
>
>
>
>
> But then I end up having the following bug:
>
>