This is an archive of the discontinued LLVM Phabricator instance.

[DAGCombine] Make sext(setcc) combine respect getBooleanContents()
ClosedPublic

Authored by mkuper on Jul 11 2016, 4:53 PM.

Details

Summary

This fixes PR28504.

Diff Detail

Event Timeline

mkuper updated this revision to Diff 63609.Jul 11 2016, 4:53 PM
mkuper retitled this revision from to [DAGCombine] Make sext(setcc) combine respect getBooleanContents().
mkuper updated this object.
mkuper added reviewers: majnemer, chandlerc.
mkuper added a subscriber: llvm-commits.
arsenm added a subscriber: arsenm.Jul 11 2016, 4:58 PM
arsenm added inline comments.
lib/CodeGen/SelectionDAG/DAGCombiner.cpp
6205

getScalarSizeInBits

6210–6223

TLI should have a getConstantTrue(VT) helper (I thought I added this a long time ago but I don't see it)

arsenm added inline comments.Jul 11 2016, 5:00 PM
test/CodeGen/X86/pr28504.ll
3–4

Usually just the triple is set on the RUN line

11

This testcase can probably be reduced

Thanks, Matt!

lib/CodeGen/SelectionDAG/DAGCombiner.cpp
6205

Right, thanks!

6210–6223

I couldn't find one either. We have an isConstTrueVal(), but not a getConstTrueVal() (I think).
Do you think this is generally useful? If so, I can factor it out into TLI.

test/CodeGen/X86/pr28504.ll
3–4

We have examples of both styles, for when we don't care about differences between triples:
test/CodeGen/X86$ grep 'target triple' *.ll | wc -l
483

Anyway, I can change this if you prefer.

11

Chandler said on the PR that he was unable to reduce it, so I haven't really tried to. I can see if there's a simpler way to trigger this.

arsenm added inline comments.Jul 11 2016, 5:20 PM
lib/CodeGen/SelectionDAG/DAGCombiner.cpp
6210–6223

Yes, there are plenty of places that have broken BooleanContent handling for targets that use -1, so more helpers would be useful

mkuper added inline comments.Jul 12 2016, 11:39 AM
lib/CodeGen/SelectionDAG/DAGCombiner.cpp
6210–6223

Actually, this is a bit problematic here. I could add a helper for getConstTrueVal, but I'd still need to special-case (SetCCWidth == 1), since in that case, I really want the sign-extension of the low bit, regardless of getBooleanContents(). So it doesn't really make the code much less cumbersome. I'll post a version of the patch with that.

mkuper updated this revision to Diff 63715.Jul 12 2016, 12:41 PM

Updated per Matt's comments.

ping * 2 :-)

chandlerc added inline comments.Jul 25 2016, 11:52 AM
lib/CodeGen/SelectionDAG/DAGCombiner.cpp
6210–6223

I'm confused....

Why wouldn't all this special casing of size one still be sunk into getConstTrueVal? I feel like I should understand this from your previous comment, but perhaps I'm being dense and don't....

6211–6214

Why not sink all of this logic into getConstTrueVal?

test/CodeGen/X86/pr28504.ll
4–5

Moving the triple to the RUN line is preferred at this point.

12

You can probably reduce it much more now that you know what to look for. I was just shooting blind. =]

Thanks, Chandler!

lib/CodeGen/SelectionDAG/DAGCombiner.cpp
6210–6223

We're combining a (sext (setcc (...)).

There are two options:

  1. The setcc's type is i1. So the sext of the "true" value is all-1s, regardless of getBooleanContents().
  2. The setcc's type is something else, say, an i8. In this case, it has already been extended - either zext, or sext, according to getBooleanContents(). So to sext it further, we want to splat the highest bit of the i8. For the "true" case, the result of this sext is the getBooleanContents-respecting true value of the right width.

I'll document this inline.

chandlerc added inline comments.Jul 25 2016, 1:12 PM
lib/CodeGen/SelectionDAG/DAGCombiner.cpp
6210–6223

Ah, I guess I see.

Maybe call this ExtTrueValue then to clarify that in the i1 case it may not match the TrueVal of the given size?

mkuper updated this revision to Diff 65436.Jul 25 2016, 4:03 PM

Another, gentle, ping.

chandlerc accepted this revision.Jul 30 2016, 1:46 AM
chandlerc edited edge metadata.

LGTM, although there is still the question of whether the test can be reduced any.

At the very least, if it cannot be reduced, please clearly comment the test case so that a future maintainer who needs to understand the intent of the test knows how to effectively update it.

This revision is now accepted and ready to land.Jul 30 2016, 1:46 AM

Thanks, Chandler!

Regarding the test case - this is actually somewhat reduced, it's 15 instructions, compared to the 29 in the PR.
The reason it's hard to reduce further is that the graph needs to be set up "just so". The combine opportunity needs to be exposed late (post-legalization), because if it happens too soon, you get an i1 SETCC, which doesn't hit the bad codepath. And I don't know of a way to directly generate an i8 (or larger) SETCC from IR.

I'll make a note of this in the test itself, although I'm not sure how helpful it will be. If the combine chain that leads to this being exposed breaks, there's nothing much you can do about that.

Thanks, Chandler!

Regarding the test case - this is actually somewhat reduced, it's 15 instructions, compared to the 29 in the PR.
The reason it's hard to reduce further is that the graph needs to be set up "just so". The combine opportunity needs to be exposed late (post-legalization), because if it happens too soon, you get an i1 SETCC, which doesn't hit the bad codepath. And I don't know of a way to directly generate an i8 (or larger) SETCC from IR.

Ah, sorry if it was already reduced further.

I'll make a note of this in the test itself, although I'm not sure how helpful it will be. If the combine chain that leads to this being exposed breaks, there's nothing much you can do about that.

Sure, but hopefully with the note some future maintainer will realize that is all that has happened and be able to confidently remove the test because the pattern that it exercised can't be reached any longer, rather than wondering forever if this was a regression or what it means for the test to change. Maybe I'm being optimistic though. ;]

mkuper closed this revision.Aug 1 2016, 12:48 PM

Closed by rL277371.