This fixes PR28504.
Diff Detail
Event Timeline
Thanks, Matt!
lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
6208 | Right, thanks! | |
6211–6215 | I couldn't find one either. We have an isConstTrueVal(), but not a getConstTrueVal() (I think). | |
test/CodeGen/X86/pr28504.ll | ||
2–3 | We have examples of both styles, for when we don't care about differences between triples: Anyway, I can change this if you prefer. | |
10 | 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. |
lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
6211–6215 | Yes, there are plenty of places that have broken BooleanContent handling for targets that use -1, so more helpers would be useful |
lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
6211–6215 | 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. |
lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
6211–6217 | 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.... | |
6212–6215 | 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 | ||
---|---|---|
6211–6217 | We're combining a (sext (setcc (...)). There are two options:
I'll document this inline. |
lib/CodeGen/SelectionDAG/DAGCombiner.cpp | ||
---|---|---|
6211–6217 | 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? |
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.
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.
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. ;]
getScalarSizeInBits