[llvm-dev] RFC: Convert Returned Constant i1 Values to i32 on PPC64

Reid Kleckner via llvm-dev llvm-dev at lists.llvm.org
Tue Oct 6 18:05:22 PDT 2015


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>


More information about the llvm-dev mailing list