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

On Thu, May 24, 2012 at 5:40 PM, Sebastian Pop <spop at codeaurora.org>
wrote:
> On Thu, May 24, 2012 at 5:06 PM, Hal Finkel <hfinkel at anl.gov>
wrote:
>> Sebastian,
>>
>> First, it might be useful to look at what is done in the PowerPC
>> backend. PPC also has condition registers that are larger than the
>> 1-bit conditional results, and it defines 1-bit subregisters in
>> addition to the larger condition registers. The spill-restore code ends
>> up being more complicated, but that, perhaps, is a separate issue. [To
>> be clear, I am not advocating for (or against) this solution even if it
>> would work for you].
>
> Ok, thanks for the pointer, I'll go read in the PPC bits.
I see that PPC has its condition registers CRRC as i32, and that PPC
also has general purpose i32 registers GPRC, so the situation is slightly
different than on Hexagon, where there are no general purpose registers
of the same size as the predicate registers: i8.

So on PPC it is "safe" to promote from i1 to i32 and to "allow
confusion"
between the promoted i32 and the existing operations that were using i32:
as we can always select between a CR and a GPR following the op type.

On Hexagon, if type legalization promotes i1 into i8, that would create
this confusion between the i8 ops existing before legalization and the
newly promoted ones.  Then as Ivan was suggesting, we will have to
provide custom expansion to promote the "illegal" ops on i8 on almost
all the operations, except logical ops.

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

On Fri, May 25, 2012 at 11:54 AM, Sebastian Pop <spop at codeaurora.org>
wrote:
> On Hexagon, if type legalization promotes i1 into i8, that would create
> this confusion between the i8 ops existing before legalization and the
> newly promoted ones.  Then as Ivan was suggesting, we will have to
> provide custom expansion to promote the "illegal" ops on i8 on
almost
> all the operations, except logical ops.
For reference, I just found out that adding a p8 type creates too many
problems in the generic code of LLVM: for instance, here is the last fail

 include/llvm/Target/TargetLowering.h:473:
llvm::TargetLowering::LegalizeAction
llvm::TargetLowering::getCondCodeAction(llvm::ISD::CondCode,
llvm::EVT) const: Assertion `(unsigned)CC <
array_lengthof(CondCodeActions) && (unsigned)VT.getSimpleVT().SimpleTy
< sizeof(CondCodeActions[0])*4 && "Table isn't big
enough!"' failed.

that looks like we would have to add some more space in a cond code
table, and we would have to specify how to handle p8 types in conditions.

I will thus use the i8 type for predicates in Hexagon, and I will deal with
the difficulties I mentioned in my previous email.

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

Hi Sebastian,

Le 25/05/2012 18:54, Sebastian Pop a écrit :
> On Thu, May 24, 2012 at 5:40 PM, Sebastian Pop<spop at
codeaurora.org>  wrote:
>> On Thu, May 24, 2012 at 5:06 PM, Hal Finkel<hfinkel at anl.gov> 
wrote:
>>> Sebastian,
>>>
>>> First, it might be useful to look at what is done in the PowerPC
>>> backend. PPC also has condition registers that are larger than the
>>> 1-bit conditional results, and it defines 1-bit subregisters in
>>> addition to the larger condition registers. The spill-restore code
ends
>>> up being more complicated, but that, perhaps, is a separate issue.
[To
>>> be clear, I am not advocating for (or against) this solution even
if it
>>> would work for you].
>> Ok, thanks for the pointer, I'll go read in the PPC bits.
> I see that PPC has its condition registers CRRC as i32, and that PPC
> also has general purpose i32 registers GPRC, so the situation is slightly
> different than on Hexagon, where there are no general purpose registers
> of the same size as the predicate registers: i8.
>
> So on PPC it is "safe" to promote from i1 to i32 and to
"allow confusion"
> between the promoted i32 and the existing operations that were using i32:
> as we can always select between a CR and a GPR following the op type.
>
> On Hexagon, if type legalization promotes i1 into i8, that would create
> this confusion between the i8 ops existing before legalization and the
> newly promoted ones.  Then as Ivan was suggesting, we will have to
> provide custom expansion to promote the "illegal" ops on i8 on
almost
> all the operations, except logical ops.
I think there is also another (and cleaner) workaround, a kind of 
operation-based type promotion of __illegal__ types.
This can be done by simply setting the operation with illegal type 
result to have a custom expander, for example:

setOperationAction(ISD::AND, MVT::i1, Custom)

See LowerOperationWrapper() & ReplaceNodeResults() hooks in 
TargetLowering. If you make this work only on logical ops, the rest will 
get automatically promoted by setting the promotion of i1 to be i32 by 
default. The latter will require a little hack though...
I hope this helps.

Ivan
>
> 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

Salut Ivan,

On Fri, Jun 1, 2012 at 7:22 AM, Ivan Llopard <ivanllopard at gmail.com>
wrote:
> Hi Sebastian,
>
> Le 25/05/2012 18:54, Sebastian Pop a écrit :
>> On Thu, May 24, 2012 at 5:40 PM, Sebastian Pop<spop at
codeaurora.org>  wrote:
>>> On Thu, May 24, 2012 at 5:06 PM, Hal Finkel<hfinkel at
anl.gov>  wrote:
>>>> Sebastian,
>>>>
>>>> First, it might be useful to look at what is done in the
PowerPC
>>>> backend. PPC also has condition registers that are larger than
the
>>>> 1-bit conditional results, and it defines 1-bit subregisters in
>>>> addition to the larger condition registers. The spill-restore
code ends
>>>> up being more complicated, but that, perhaps, is a separate
issue. [To
>>>> be clear, I am not advocating for (or against) this solution
even if it
>>>> would work for you].
>>> Ok, thanks for the pointer, I'll go read in the PPC bits.
>> I see that PPC has its condition registers CRRC as i32, and that PPC
>> also has general purpose i32 registers GPRC, so the situation is
slightly
>> different than on Hexagon, where there are no general purpose registers
>> of the same size as the predicate registers: i8.
>>
>> So on PPC it is "safe" to promote from i1 to i32 and to
"allow confusion"
>> between the promoted i32 and the existing operations that were using
i32:
>> as we can always select between a CR and a GPR following the op type.
>>
>> On Hexagon, if type legalization promotes i1 into i8, that would create
>> this confusion between the i8 ops existing before legalization and the
>> newly promoted ones.  Then as Ivan was suggesting, we will have to
>> provide custom expansion to promote the "illegal" ops on i8
on almost
>> all the operations, except logical ops.
>
> I think there is also another (and cleaner) workaround, a kind of
> operation-based type promotion of __illegal__ types.
> This can be done by simply setting the operation with illegal type
> result to have a custom expander, for example:
>
> setOperationAction(ISD::AND, MVT::i1, Custom)
>
I was exploring something similar using exactly this function.
> See LowerOperationWrapper() & ReplaceNodeResults() hooks in
> TargetLowering. If you make this work only on logical ops, the rest will
> get automatically promoted by setting the promotion of i1 to be i32 by
I think I was not clear enough in my past emails, so let me try again:

As I am specifying that predicate registers are i8, LLVM considers i8
to be a legal type.  i1 is then automatically promoted to the next
larger legal type, that is i8: this is the correct behavior.

The problem is that the existing integer arithmetic operations on i8
are not legal to be executed on the predicate registers (i.e., clang
would generate an i8 expression for the addition of two char
variables.)  Hexagon cannot do integer arithmetic operations using the
predicate registers.  The addition of two char variables has to be
promoted to the next available integer arithmetic register: that is
i32.  Because LLVM automatically legalizes i8 types, it considers all
operations to be legal on i8 (i.e., both integer and boolean arithmetic.)

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
> default. The latter will require a little hack though...
> I hope this helps.
Thanks again for your ideas and guidance: very much appreciated.

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