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

Hi Eli,

On Thu, Mar 1, 2012 at 2:21 PM, Eli Friedman <eli.friedman at gmail.com>
wrote:
> On Tue, Feb 28, 2012 at 11:17 AM, Tony Linthicum <tlinth at
codeaurora.org> wrote:
>> Hey folks,
>>
>> We are having some difficulty with how we have been representing our
>> predicate registers, and wanted some advice from the list.  First, we
>> had been representing our predicate registers as 1 bit (i1).  The
truth,
>> however, is that they are 8 bits.  The reason for this is that they
>> serve as predicates for conditional execution of instructions,  branch
>> condition codes, and also as vector mask registers for conditional
>> selection of vector elements.
>>
>> We have run into problems with type mismatches with intrinsics for some
>> of our vector operations.  We decided to try to solve it by
representing
>> the predicate registers as what they really are, namely i8.  We changed
>> our intrinsic and instruction definitions accordingly, changed the data
>> type of the predicate registers to be i8, and changed
>> getSetCCResultType() to return i8.  After doing this, the compiler
>> builds just fine but dies at runtime trying to match some target
>> independent operations (e.g. setcc/brcond) that appear to want an i1
for
>> the condition code.
>>
>> So, my question is this: is it even possible to represent our predicate
>> registers (and our condition codes) as i8, and if so, what hook are we
>> missing?
>
> Making getSetCCResultType return i8 is definitely supported, and
> brcond should be okay with that.  It's not obvious what is going
> wrong; are you sure there isn't anything in your target still
> expecting an i1?
I have specified that Hexagon has an i8 predicate register that
represents the true predicate as -1 with a sign extend like this:

    addRegisterClass(MVT::i8, &Hexagon::PredRegsRegClass);
    setBooleanContents(ZeroOrNegativeOneBooleanContent);

and I'm calling this code just before computeRegisterProperties, that
builds the TransformToType table specifying the type promotions:

i1  -> i8
i8  -> i8 (legal)
i16 -> i32
i32 -> i32 (legal)

This would be fine if the register for i8 could be used for any
integer operation (as in x86 for instance), but on Hexagon, predicate
registers can only be used in a few logical operations.

So my question is how do we specify that for most of the operations i8
should be promoted to i32 and that only a few logical operations are
legal on i8?

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

PS: I have tried to tweak the TransformToType table to specify the
type promotion i8 -> i32, by doing the following just after the call
to computeRegisterProperties:

    RegisterTypeForVT[MVT::i8] = TransformToType[MVT::i8] = MVT::i32;

and then legalize the SETCC on i8 and specify that for example the
results of loads should be in i32 regs:

    setOperationAction(ISD::SETCC, MVT::i8, Legal);
    [...]
    setOperationAction(ISD::LOAD, MVT::i8, Promote);
    [...]

Hi Sebastian,

On 22/05/2012 23:25, Sebastian Pop wrote:
> Hi Eli,
>
> On Thu, Mar 1, 2012 at 2:21 PM, Eli Friedman<eli.friedman at
gmail.com>  wrote:
>> On Tue, Feb 28, 2012 at 11:17 AM, Tony Linthicum<tlinth at
codeaurora.org>  wrote:
>>> Hey folks,
>>>
>>> We are having some difficulty with how we have been representing
our
>>> predicate registers, and wanted some advice from the list.  First,
we
>>> had been representing our predicate registers as 1 bit (i1).  The
truth,
>>> however, is that they are 8 bits.  The reason for this is that they
>>> serve as predicates for conditional execution of instructions, 
branch
>>> condition codes, and also as vector mask registers for conditional
>>> selection of vector elements.
>>>
>>> We have run into problems with type mismatches with intrinsics for
some
>>> of our vector operations.  We decided to try to solve it by
representing
>>> the predicate registers as what they really are, namely i8.  We
changed
>>> our intrinsic and instruction definitions accordingly, changed the
data
>>> type of the predicate registers to be i8, and changed
>>> getSetCCResultType() to return i8.  After doing this, the compiler
>>> builds just fine but dies at runtime trying to match some target
>>> independent operations (e.g. setcc/brcond) that appear to want an
i1 for
>>> the condition code.
>>>
>>> So, my question is this: is it even possible to represent our
predicate
>>> registers (and our condition codes) as i8, and if so, what hook are
we
>>> missing?
>>
>> Making getSetCCResultType return i8 is definitely supported, and
>> brcond should be okay with that.  It's not obvious what is going
>> wrong; are you sure there isn't anything in your target still
>> expecting an i1?
>
> I have specified that Hexagon has an i8 predicate register that
> represents the true predicate as -1 with a sign extend like this:
>
>      addRegisterClass(MVT::i8,&Hexagon::PredRegsRegClass);
>      setBooleanContents(ZeroOrNegativeOneBooleanContent);
>
> and I'm calling this code just before computeRegisterProperties, that
> builds the TransformToType table specifying the type promotions:
>
> i1  ->  i8
> i8  ->  i8 (legal)
> i16 ->  i32
> i32 ->  i32 (legal)
>
> This would be fine if the register for i8 could be used for any
> integer operation (as in x86 for instance), but on Hexagon, predicate
> registers can only be used in a few logical operations.
>
> So my question is how do we specify that for most of the operations i8
> should be promoted to i32 and that only a few logical operations are
> legal on i8?
I think the combo TargetLowerInfo::isTypeDesirableForOp() and 
IsDesirableToPromoteOp() may help you here. X86 does something similar.

Ivan
>
> Thanks,
> Sebastian
> --
> Qualcomm Innovation Center, Inc is a member of Code Aurora Forum
>
> PS: I have tried to tweak the TransformToType table to specify the
> type promotion i8 ->  i32, by doing the following just after the call
> to computeRegisterProperties:
>
>      RegisterTypeForVT[MVT::i8] = TransformToType[MVT::i8] = MVT::i32;
>
> and then legalize the SETCC on i8 and specify that for example the
> results of loads should be in i32 regs:
>
>      setOperationAction(ISD::SETCC, MVT::i8, Legal);
>      [...]
>      setOperationAction(ISD::LOAD, MVT::i8, Promote);
>      [...]
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Hi Ivan,

On Tue, May 22, 2012 at 5:09 PM, Ivan Llopard <ivanllopard at gmail.com>
wrote:
> Hi Sebastian,
>
> On 22/05/2012 23:25, Sebastian Pop wrote:
>> So my question is how do we specify that for most of the operations i8
>> should be promoted to i32 and that only a few logical operations are
>> legal on i8?
>
> I think the combo TargetLowerInfo::isTypeDesirableForOp() and
> IsDesirableToPromoteOp() may help you here. X86 does something similar.
I just tried these functions, and it seems like they are only
modifying the behavior of type promotions for a small subset of
operations (PromoteIntBinOp, PromoteIntShiftOp, PromoteExtend,
PromoteLoad, SimplifyBinOpWithSameOpcodeHands, visitSRL, visitTRUNCATE
that matter to the performance of i16 on X86.)

I don't like the "desirable" in the name of these functions: in
the
case of Hexagon it is illegal to use an i8 predicate register for
anything else than setcc, brcond, and the logical ops: so doing the
conversion is a matter of correctness, not of desirability.

Should I add a call to IsDesirableToPromoteOp in every other operation
that is currently missing this check for type promotion, or do we want
a new hook?

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