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

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

Hi,

On Tue, May 22, 2012 at 11:35 PM, Sebastian Pop <spop at codeaurora.org>
wrote:
> 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?
I found it pretty difficult to modify the existing DAG combiner to add the
missing calls to isDesirableToPromoteOp, so I abandoned this path.

I found it easier to work with a new integer type p8 for the 8 bit
predicates, such that I can promote i1 into p8 and avoid the confusion
of integer and predicate registers that I had when using the same i8 type.

Would a patch adding the p8 type be ok to commit to llvm?

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

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].

Second, generically speaking, the problem that you
have seems much more general than the solution you propose. Correct
me if I'm wrong, but your fundamental issue is that you have a type, i8,
than can exist in different register classes, and the operations that
are legal on that type depend on the current register class. The reason
this is a problem is that legalization happens before register-class
assignment.

Currently, isTypeLegal does not take an opcode parameter, but maybe
changing it to depend on the type of operation (like getTypeToPromoteTo
does) and the opcode of the node's inputs would help?

 -Hal

On Thu, 24 May 2012 16:11:30 -0500
Sebastian Pop <spop at codeaurora.org> wrote:
> Hi,
> 
> On Tue, May 22, 2012 at 11:35 PM, Sebastian Pop <spop at
codeaurora.org>
> wrote:
> > 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?
> 
> I found it pretty difficult to modify the existing DAG combiner to
> add the missing calls to isDesirableToPromoteOp, so I abandoned this
> path.
> 
> I found it easier to work with a new integer type p8 for the 8 bit
> predicates, such that I can promote i1 into p8 and avoid the confusion
> of integer and predicate registers that I had when using the same i8
> type.
> 
> Would a patch adding the p8 type be ok to commit to llvm?
> 
> 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