llvm dev - Oct 2015 - RFC: Convert Returned Constant i1 Values to i32 on PPC64

Presently, on PPC64 there is some silliness regarding on constant
boolean values are allocated to registers. Specifically, when crbits
are enabled, these values tend to be allocated to cr registers even
though the calling convention stipulates that they be returned in gp
registers. Additionally, constant booleans tracking control flow
through functions tend to be live for the entire function and
consequently are allocated to non-volatile registers, forcing a
non-volatile cr register to be saved and restored.

I have created a patch to address this issue
(http://reviews.llvm.org/differential/diff/36688/) and would
appreciate some feedback. The pass I implemented is quite simple and
only handles the very specific situation of constant boolean values
passing through PHINode to RetInsts. There is somewhat similar logic
already present in PPCISelLowering.cpp (DAGCombineExtBoolTrunc and
DAGCombineExtBoolTrunc). Originally, I hoped to either add logic to
PPCISelLowering to handle this case or write a new pass encompassing
the PPCISelLowering logic. However, neither design proved viable. The
existing PPCISelLowering functionality is based on SelectionDAGs and
consequently operates on BasicBlock scope, rather than Function-level
scope needed for this pass. The existing PPCISelLowering logic could
not be incorporated into the new LLVM IR level pass, since lowering to
MachineInsts creates new Trunc and Ext operations that are not present
at the LLVM IR level. I feel a little guilty proposing something that
is fairly special purpose, but I don't see a way to generalize the
logic in this pass in a useful way.

Thanks.
Tom

You can add target specific codegen prepare style passes in
PPCPassConfig::addIRPasses(). There's already some PPC specific stuff there.

On Tue, Oct 6, 2015 at 5:58 PM, Thomas Jablin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Presently, on PPC64 there is some silliness regarding on constant
> boolean values are allocated to registers. Specifically, when crbits
> are enabled, these values tend to be allocated to cr registers even
> though the calling convention stipulates that they be returned in gp
> registers. Additionally, constant booleans tracking control flow
> through functions tend to be live for the entire function and
> consequently are allocated to non-volatile registers, forcing a
> non-volatile cr register to be saved and restored.
>
> I have created a patch to address this issue
> (http://reviews.llvm.org/differential/diff/36688/) and would
> appreciate some feedback. The pass I implemented is quite simple and
> only handles the very specific situation of constant boolean values
> passing through PHINode to RetInsts. There is somewhat similar logic
> already present in PPCISelLowering.cpp (DAGCombineExtBoolTrunc and
> DAGCombineExtBoolTrunc). Originally, I hoped to either add logic to
> PPCISelLowering to handle this case or write a new pass encompassing
> the PPCISelLowering logic. However, neither design proved viable. The
> existing PPCISelLowering functionality is based on SelectionDAGs and
> consequently operates on BasicBlock scope, rather than Function-level
> scope needed for this pass. The existing PPCISelLowering logic could
> not be incorporated into the new LLVM IR level pass, since lowering to
> MachineInsts creates new Trunc and Ext operations that are not present
> at the LLVM IR level. I feel a little guilty proposing something that
> is fairly special purpose, but I don't see a way to generalize the
> logic in this pass in a useful way.
>
> Thanks.
> Tom
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151006/77c4a3ed/attachment.html>