[LLVMdev] Predicate registers/condition codes question

Sebastian Pop spop at codeaurora.org
Tue Jun 19 15:12:59 PDT 2012


Hi Hal,

On Thu, Jun 7, 2012 at 11:42 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> On Mon, 4 Jun 2012 11:41:43 -0500
> Sebastian Pop <spop at codeaurora.org> wrote:
>
>> On Mon, Jun 4, 2012 at 11:22 AM, Sebastian Pop <spop at codeaurora.org>
>> wrote:
>> >> Why don't you call it with "Promote" instead of
>> >> "Custom" and let the Legalizer do the job? Does it not work?
>> >
>> > I tried this, and the legalizer will happily say that i8 is a legal
>> > type and just return the exact same node: this is because we
>> > declared that Hexagon has a register for i8, that makes i8 legal
>> > for all promotions.
>>
>> As Hal mentioned, the problem is linked to the fact that type
>> legalization happens before register class assignments.
>>
>> One way to solve this problem would be to teach type legalization
>> about the predicate register class: if a processor can perform only
>> boolean arithmetic it would declare a type to be in the PredRegs
>> class, whereas a processor that can do both integer and boolean
>> arithmetic on a type would declare the register to be in both the
>> IntRegs and PredRegs class, or just in the IntRegs class.
>>
>> Opinions?  How hard is it to teach type legalization about register
>> classes?
>>
>
> Out of curiosity, have you some up with a workable scheme for this?

Yes, what Ivan has suggested is starting to work: we mark "Promote"
all the operations that cannot be computed using a predicate register,
and we specify that the promotion type is i32.  Only the few boolean
operations remain "Legal" on the i8 type.

Sirish is now going in review over all the patterns in the back-end to
make sure it fits well with the new type for predicates.

Sebastian

> FWIW, PowerPC also has these predicate boolean-operation instructions.
> Currently, the backend does not even know about them, but it might be
> worth changing that.
>
> If nothing else, maybe some kind of pre-register-allocation
> peephole pass would be sufficient: A pass that looks for boolean
> operations where all inputs have just been copied from the predicate
> registers, and replaces the operation with the predicate operation (and
> a copy-out). Or if you arrange things so that you have the opposite
> problem, add pseudo instructions (for everything else) and have the
> peephole pass (or regular pseudo expansion) pull the operands into
> regular registers and then replace the pseudo with the real operation.
>
>  -Hal
>
>> 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
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



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




More information about the llvm-dev mailing list