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

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?

Thanks in advance for any help you might be able to provide.

Tony

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

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?

-Eli

On 3/1/2012 2:21 PM, Eli Friedman 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?
>
> -Eli
Thanks, Eli.  We'll take another look at our target dependent 
information to see if some i1's are still lurking about.  It's good to 
know that this should work.

Tony

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

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);
    [...]