llvm dev - Jun 2012 - [LLVMdev] Predicate registers/condition codes question

On Sun, Jun 3, 2012 at 7:11 AM, Ivan Llopard <ivanllopard at gmail.com>
wrote:
>> So the solution that I was investigating looks like this:
>>
>>      for (unsigned int i = 0; i<  ISD::BUILTIN_OP_END; ++i) {
>>        switch (i) {
>>        // By default all operations on i8 have to be promoted to i32.
>>        default:
>>          setOperationAction(i, MVT::i8, Custom);
>>          break;
>>
>>        // Only the following operations are legal on i8 predicates.
>>        case ISD::AND:
>>        case ISD::OR:
>>        case ISD::XOR:
>>        case ISD::SETCC:
>>        case ISD::SIGN_EXTEND:
>>         break;
>>        }
>>      }
>>
>> and promote all i8 to i32 in HexagonTargetLowering::LowerOperation
>
> That's hard work!
Indeed, that was my concern as well: that's why I tried to avoid using
i8 for predicates and use p8, but now I know that is a dead-end.
> Why don't you call it with "Promote" instead of
> "Custom" and let the Legalizer do the job? Does it not work?
I tried this, and the legalizer will happily say that i8 is a legal type
and just return the exact same node: this is because we declared
that Hexagon has a register for i8, that makes i8 legal for all
promotions.

Sebastian
--
Qualcomm Innovation Center, Inc is a member of Code Aurora Forum

On Mon, Jun 4, 2012 at 11:22 AM, Sebastian Pop <spop at codeaurora.org>
wrote:
>> Why don't you call it with "Promote" instead of
>> "Custom" and let the Legalizer do the job? Does it not work?
>
> I tried this, and the legalizer will happily say that i8 is a legal type
> and just return the exact same node: this is because we declared
> that Hexagon has a register for i8, that makes i8 legal for all
> promotions.
As Hal mentioned, the problem is linked to the fact that type legalization
happens before register class assignments.

One way to solve this problem would be to teach type legalization about
the predicate register class: if a processor can perform only boolean
arithmetic it would declare a type to be in the PredRegs class, whereas
a processor that can do both integer and boolean arithmetic on a type
would declare the register to be in both the IntRegs and PredRegs class,
or just in the IntRegs class.

Opinions?  How hard is it to teach type legalization about register classes?

Thanks,
Sebastian
--
Qualcomm Innovation Center, Inc is a member of Code Aurora Forum

On 04/06/2012 18:22, Sebastian Pop wrote:
> On Sun, Jun 3, 2012 at 7:11 AM, Ivan Llopard<ivanllopard at
gmail.com>  wrote:
>>> So the solution that I was investigating looks like this:
>>>
>>>       for (unsigned int i = 0; i<    ISD::BUILTIN_OP_END; ++i) {
>>>         switch (i) {
>>>         // By default all operations on i8 have to be promoted to
i32.
>>>         default:
>>>           setOperationAction(i, MVT::i8, Custom);
>>>           break;
>>>
>>>         // Only the following operations are legal on i8
predicates.
>>>         case ISD::AND:
>>>         case ISD::OR:
>>>         case ISD::XOR:
>>>         case ISD::SETCC:
>>>         case ISD::SIGN_EXTEND:
>>>          break;
>>>         }
>>>       }
>>>
>>> and promote all i8 to i32 in HexagonTargetLowering::LowerOperation
>> That's hard work!
> Indeed, that was my concern as well: that's why I tried to avoid using
> i8 for predicates and use p8, but now I know that is a dead-end.
>
>> Why don't you call it with "Promote" instead of
>> "Custom" and let the Legalizer do the job? Does it not work?
> I tried this, and the legalizer will happily say that i8 is a legal type
> and just return the exact same node: this is because we declared
> that Hexagon has a register for i8, that makes i8 legal for all
> promotions.
Indeed, that's what the TypeLegalizer is intended to do. On the other 
hand, the SelectionDAGLegalizer has the mechanics to promote legal nodes 
to the next legal type as requested by setOperationAction(). I tested it 
on my BE and I could see that not all isd nodes are handled yet. May be 
more cases should be added to SelectionDAGLegalize::PromoteNode() ?

Ivan
> Sebastian
> --
> Qualcomm Innovation Center, Inc is a member of Code Aurora Forum

On Mon, 4 Jun 2012 11:41:43 -0500
Sebastian Pop <spop at codeaurora.org> wrote:
> On Mon, Jun 4, 2012 at 11:22 AM, Sebastian Pop <spop at
codeaurora.org>
> wrote:
> >> Why don't you call it with "Promote" instead of
> >> "Custom" and let the Legalizer do the job? Does it not
work?
> >
> > I tried this, and the legalizer will happily say that i8 is a legal
> > type and just return the exact same node: this is because we
> > declared that Hexagon has a register for i8, that makes i8 legal
> > for all promotions.
> 
> As Hal mentioned, the problem is linked to the fact that type
> legalization happens before register class assignments.
> 
> One way to solve this problem would be to teach type legalization
> about the predicate register class: if a processor can perform only
> boolean arithmetic it would declare a type to be in the PredRegs
> class, whereas a processor that can do both integer and boolean
> arithmetic on a type would declare the register to be in both the
> IntRegs and PredRegs class, or just in the IntRegs class.
> 
> Opinions?  How hard is it to teach type legalization about register
> classes?
> 
Out of curiosity, have you some up with a workable scheme for this?
FWIW, PowerPC also has these predicate boolean-operation instructions.
Currently, the backend does not even know about them, but it might be
worth changing that.

If nothing else, maybe some kind of pre-register-allocation
peephole pass would be sufficient: A pass that looks for boolean
operations where all inputs have just been copied from the predicate
registers, and replaces the operation with the predicate operation (and
a copy-out). Or if you arrange things so that you have the opposite
problem, add pseudo instructions (for everything else) and have the
peephole pass (or regular pseudo expansion) pull the operands into
regular registers and then replace the pseudo with the real operation.

 -Hal
> Thanks,
> Sebastian
> --
> Qualcomm Innovation Center, Inc is a member of Code Aurora Forum
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory