This is an archive of the discontinued LLVM Phabricator instance.

[DAGCombiner] Recognize more patterns for ABS
ClosedPublic

Authored by kparzysz on Jun 6 2018, 9:07 AM.

Details

Summary

The Hexagon backend had these recognized in selection patterns. Make the combiner get them instead. One case was already covered, but it failed when the XOR operands were switched.

Diff Detail

Repository
rL LLVM

Event Timeline

kparzysz created this revision.Jun 6 2018, 9:07 AM

The subtract version was noted in PR36036:
https://bugs.llvm.org/show_bug.cgi?id=36036

And as commented there, we're now canonicalizing in IR to the form with select:
D40984

And there were more IR improvements for abs() here:
D47041
D47076
D47631

...so can we add the IR canonicalization for the subtract version (solve PR36036) and be done with this? Ie, can we already remove the DAG combine for the half-implemented 'add' version because we're confident that IR is now always going to be in the canonical 'select' form? Is there some place in the DAG that creates abs() in a non-canonical form?

While I remember ValueTracking matches SPF_ABS/SPF_NABS selection style patterns - but SelectionDAGBuilder::visitSelect still doesn't support SPF_ABS/SPF_NABS which prevents it being used

There are functions in test/CodeGen/Hexagon/abs.ll that will fail without the changes in visitXOR (the "add" pattern).

I see what you mean... Adding the sub variant to instcombine, not dagcombine, and deleting all abs from dagcombine. Yes, that should work.

I see what you mean... Adding the sub variant to instcombine, not dagcombine, and deleting all abs from dagcombine. Yes, that should work.

Great - I'll add that (simple translation of D40984) if you're not already doing it.

I think nobody is ever quite sure when the IR improvements allow us to remove DAG folds, so we end up with largely dead code in the backend.

But Simon raises a point that has come up before - we should be producing ABS nodes in SelectionDAGBuilder similar to how we already produce MIN/MAX. We'll want to do that before deleting any DAGCombiner code.

Is is possible to end up with the abs patterns after simplifying/legalizing an existing DAG, without having them exposed in the IR earlier on?

Is is possible to end up with the abs patterns after simplifying/legalizing an existing DAG, without having them exposed in the IR earlier on?

I can't rule it out completely, but that seems very unlikely given that we have a generic ABS node. Some set of smaller DAG transforms would have to unknowingly produce the shift+xor+add/sub instructions independently without realizing it has created the larger ABS node?

I can't rule it out completely, but that seems very unlikely given that we have a generic ABS node. Some set of smaller DAG transforms would have to unknowingly produce the shift+xor+add/sub instructions independently without realizing it has created the larger ABS node?

Yes, that's what I meant. I've seen a similar kind of behavior before (different operations though). I can try to create a testcase that shows that. Is this simply something that we assume could happen and have to live with?

I can't rule it out completely, but that seems very unlikely given that we have a generic ABS node. Some set of smaller DAG transforms would have to unknowingly produce the shift+xor+add/sub instructions independently without realizing it has created the larger ABS node?

Yes, that's what I meant. I've seen a similar kind of behavior before (different operations though). I can try to create a testcase that shows that. Is this simply something that we assume could happen and have to live with?

No, if it's likely, then we should have a DAGCombine for it. We want the IR canonicalization regardless of that though, so I'll work on the InstCombine patch.

spatel added a comment.Jun 6 2018, 3:54 PM

Here's the instcombine patch:
rL334137

If we want to keep going with a DAG patch, we'll need codegen tests. A basic x86 example is shown in PR36036.

A more involved case with multiple uses of the intermediate values would thwart the IR transform, so that would be a good test for either this patch or the value tracking + SelectionDAGBuilder suggestion.

If we want to keep going with a DAG patch, we'll need codegen tests. A basic x86 example is shown in PR36036.

Codegen tests already exist: test/CodeGen/Hexagon/abs.ll. That testcase used to rely on Hexagon-specific selection patterns, which this patch removes.

kparzysz updated this revision to Diff 150353.Jun 7 2018, 9:31 AM

Added a check for reversed order of add operands.

Added a test with multiple uses of the sign bit copy, and with the order of add's operands reversed.

RKSimon added inline comments.Jun 8 2018, 2:19 AM
lib/CodeGen/SelectionDAG/DAGCombiner.cpp
5655 ↗(On Diff #150353)

Brackets for clarity : (OpSizeInBits - 1)

lib/Target/ARM/ARMInstrNEON.td
5399 ↗(On Diff #150353)

Is there existing test coverage for these?

kparzysz marked an inline comment as done.Jun 8 2018, 5:40 AM
kparzysz added inline comments.
lib/CodeGen/SelectionDAG/DAGCombiner.cpp
5655 ↗(On Diff #150353)

I actually removed them for clarity (I forgot about the "sub" case)...

lib/Target/ARM/ARMInstrNEON.td
5399 ↗(On Diff #150353)

test/CodeGen/ARM/neon_vabs.ll failed without those. I think the patterns above it will no longer be triggered actually, but I didn't want to remove them.

kparzysz updated this revision to Diff 150489.Jun 8 2018, 5:41 AM
kparzysz marked an inline comment as done.

Add the parentheses back.

RKSimon added subscribers: rengolin, jmolloy.
RKSimon added inline comments.
lib/Target/ARM/ARMInstrNEON.td
5399 ↗(On Diff #150353)

@jmolloy @rengolin Any thoughts?

efriedma added inline comments.
lib/Target/ARM/ARMInstrNEON.td
5399 ↗(On Diff #150353)

The new patterns look fine; please delete the old patterns.

kparzysz updated this revision to Diff 150941.Jun 12 2018, 7:01 AM

Removed unnecessary patterns from ARMInstrNEON.td, changed the SUB pattern to recognize XOR operands in reversed order.

kparzysz added inline comments.Jun 12 2018, 7:03 AM
lib/Target/ARM/ARMInstrNEON.td
5400 ↗(On Diff #150941)

This should say VABDL, not VABD. I'll fix it before commit.

This revision is now accepted and ready to land.Jun 12 2018, 2:35 PM
This revision was automatically updated to reflect the committed changes.