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

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

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.
> 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.
Yes, that's correct.
> 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?
I will try to see if I can fix isTypeLegal.
Thanks for your helpful comments.

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

On 25/05/2012 00:40, Sebastian Pop 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.
>
>> 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.
>
> Yes, that's correct.
>
>> 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?
>
> I will try to see if I can fix isTypeLegal.
> Thanks for your helpful comments.
Just an idea, you may know that it's possible to custom expand 
operations with illegal types and it might be useful in this case 
(considering i1 as illegal). The TypeLegalizer will callback to your 
lowering function at the very beginning of the Combining/Legalization 
phases. If you add HexagonISD nodes in the process while promoting 
operands/result, you will be able to precisely match them later with its 
associated regclass (PReg?).
Unfortunately, it will not resolve your problem with non-allowed ops for 
i8 types and I think I'm missing something regarding this matter. Why 
don't you mark for promotion everything but logical ops ? Are copies 
between pred regs and IntRegs not allowed ?

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

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