This is an archive of the discontinued LLVM Phabricator instance.

[PowerPC] Sign extend the select instr operands if it is any_extend
AbandonedPublic

Authored by steven.zhang on Jun 20 2019, 2:03 AM.

Details

Summary

Though we have the patch https://reviews.llvm.org/D63318 to fold the aext + select in DAGCombine, PowerPC still have own combine rule to do this. However, it didn't handle the any extend well. For now, we will do the zero extend if the select operands are constant and it is fed by any_extend.

    t1: i8 = select t0, Constant:i8<-1>, Constant:i8<0>
    t2: i64 = any_extend t1
-->
    t3: i64 = select t0, Constant:i64<255>, Constant:i64<0>

The zero extend break the special pattern of "-1" and it might hurt some performance opportunity if they are caring about the sign bit.

This is what we want to do:

    t1: i8 = select t0, Constant:i8<-1>, Constant:i8<0>
    t2: i64 = any_extend t1
-->
    t3: i64 = select t0, Constant:i64<-1>, Constant:i64<0>
-->
    t4: i64 = sign_extend_inreg t3

Diff Detail

Event Timeline

steven.zhang created this revision.Jun 20 2019, 2:03 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 20 2019, 2:03 AM
steven.zhang edited the summary of this revision. (Show Details)Jun 20 2019, 2:04 AM
steven.zhang added a comment.EditedJun 25 2019, 2:34 AM

Hi, @hfinkel
As this was added by you in https://reviews.llvm.org/rL202451, would you please help me review this patch ? And I also commit another patch(https://reviews.llvm.org/D63318) to fold this pattern in DAGCombine. Would you please take a look together ? Thank you!

hfinkel added inline comments.Jun 25 2019, 6:52 PM
llvm/lib/Target/PowerPC/PPCISelLowering.cpp
12325

This seems like we're working around a problem elsewhere. Why does forcing any_extend to become a sign_extend produce better code than just producing an any_extend?

llvm/test/CodeGen/PowerPC/bool-math.ll
9

Is this a regression - it looks like we're going from two instructions to three?

steven.zhang marked 2 inline comments as done.Jun 25 2019, 7:10 PM
steven.zhang added inline comments.
llvm/lib/Target/PowerPC/PPCISelLowering.cpp
12325

For any_extend, it is handled as zero extend if it is constant. For example,

t1: i8 = select t0, Constant:i8<-1>, Constant:i8<0>
t2: i64 = any_extend t1

It will be combined as follows, for now:

t3: i64 = select t0, Constant:i64<255>, Constant:i64<0>

And the literal "255" is just a normal constant, therefore, the combine to inreg rule won't apply. This is what we expected:

t3: i64 = select t0, Constant:i64<-1>, Constant:i64<0>

So that, the combine to inreg rule would apply and it is combined as:
t4: i64 = sign_extend_inreg t3

Doing zero extend will hurt some opportunities, while sign extend indeed helps. And we haven't seen the downside yet.

llvm/test/CodeGen/PowerPC/bool-math.ll
9

No, both are three instructions.

hfinkel added inline comments.Jun 25 2019, 7:24 PM
llvm/lib/Target/PowerPC/PPCISelLowering.cpp
12325

Doing zero extend will hurt some opportunities, while sign extend indeed helps. And we haven't seen the downside yet.

What happens if we always prefer to lower any_extend to sign_extend instead of just doing it in this special case? Given that, on PPC, immediates are generally sign extended, etc., maybe that should be the default?

llvm/test/CodeGen/PowerPC/bool-math.ll
9

Ah, indeed. Thanks.

steven.zhang marked an inline comment as done.Jun 25 2019, 7:49 PM
steven.zhang added inline comments.
llvm/lib/Target/PowerPC/PPCISelLowering.cpp
12325

Yes, I tried. For powerpc, I didn't see any problems by doing this, but also no benefit from the sanity test and benchmark 2017, but for X86, I indeed see many bad changes. I guess they have some assumption on this. So, I decide to just do it for aext + select.

hfinkel added inline comments.Jun 25 2019, 8:02 PM
llvm/lib/Target/PowerPC/PPCISelLowering.cpp
12325

Is this the code that's going it:

case ISD::ANY_EXTEND:
case ISD::ZERO_EXTEND:
  return getConstant(Val.zextOrTrunc(VT.getSizeInBits()), DL, VT,
                     C->isTargetOpcode(), C->isOpaque());

(in SelectionDAG::getNode)?

Also, maybe we should override TLI.isSExtCheaperThanZExt and propose tying this behavior to the result of that callback? It seems like we should be able to change this on PPC without affecting x86.

steven.zhang marked an inline comment as done.Jun 25 2019, 8:25 PM
steven.zhang added inline comments.
llvm/lib/Target/PowerPC/PPCISelLowering.cpp
12325

Sounds work. However, I still have some concern that, sext really is cheaper than zext in PowerPC ? The reason why we want to do signed extend is that, if will break some pattern for select combine rule, not because of it is cheaper...

Anyway, I will try it first.
Inside SelectionDAG::getNode, call hook TLI.isSExtCheaperThanZExt to decide how to promote the any extend constant.

hfinkel added inline comments.Jun 25 2019, 8:32 PM
llvm/lib/Target/PowerPC/PPCISelLowering.cpp
12325

Sounds work. However, I still have some concern that, sext really is cheaper than zext in PowerPC ?

I think that it depends on the context; but any_extend is supposed to allow us to do something smart (and target influenced), and so let's see if we can make it a little smarter and get a broader benefit.

steven.zhang abandoned this revision.Jul 21 2019, 8:03 PM

Abandon this revision, as most opportunity has been fixed by https://reviews.llvm.org/rL202451.