This is an archive of the discontinued LLVM Phabricator instance.

[TargetLowering] Allow constants with multiple uses
AbandonedPublic

Authored by dstuttard on Nov 22 2019, 4:06 AM.

Details

Summary

Multiple uses of a constant was causing an assert in target lowering for
propagating fnegs. Allow multiple uses when it is a constant fixes the issue.

Change-Id: Iffd1ce18bf13ec68d91ff47aecd7cf1918fd3c0a

Event Timeline

dstuttard created this revision.Nov 22 2019, 4:06 AM
lebedev.ri added inline comments.
llvm/test/CodeGen/AMDGPU/const-multiuse-tl.ll
2

This test doesn't actually check anything.

dstuttard updated this revision to Diff 230631.Nov 22 2019, 4:21 AM

Included wrong version of the test initially

dstuttard marked 2 inline comments as done.Nov 22 2019, 4:23 AM
dstuttard added inline comments.
llvm/test/CodeGen/AMDGPU/const-multiuse-tl.ll
2

Yes, spotted it just after I uploaded. It does now. It's really only testing that it doesn't assert.

dstuttard marked an inline comment as done.
dstuttard added a subscriber: RKSimon.

Added @RKSimon to review as the last major modifier of the code here.

RKSimon added inline comments.
llvm/test/CodeGen/AMDGPU/const-multiuse-tl.ll
2

Is this reduced as much as possible (both in terms of instructions and metadata)?

dstuttard marked an inline comment as done.Nov 22 2019, 5:04 AM

I've got some failures as a result of this change in X86 (haven't tried the other backends). I guess that the failures are probably due to the fneg propagation working better for constants - but I haven't investigated yet. There will need to be more test changes as a result of this change.
My question is - does the change look reasonable? If so I'll take a look at the lit regressions for other backends.

llvm/test/CodeGen/AMDGPU/const-multiuse-tl.ll
2

I've attempted to reduce it as much as possible - I did attempt to reduce it further but that stopped the problem occurring.
I might be able to reduce the metadata more.

I'd like to see more of the regressions on other targets (x86 in particular) - in many cases this will cause a lot of extra constant pool entries.

I'd like to see more of the regressions on other targets (x86 in particular) - in many cases this will cause a lot of extra constant pool entries.

Ok - I'' take a look at those and upload some patches.

I'm more than happy if this can be solved in a different way - the issue isn't an optimisation opportunity, it is actually causing a problem with the attached example due to the difference between checking isNegatibleForFree (and it syaing it is) and it then finding a problem in getNegatedExpression when it returns a different (and unexpected) result from a call to isNegatableForFree when handling an ISD::FMA.

I'd be more interested in fixing the isNegatibleForFree/getNegatedExpression mismatch - the next step for PR42863 will be to convert AMDGPU's performFNegCombine to TLI isNegatibleForFree/getNegatedExpression callbacks like X86.

dstuttard updated this revision to Diff 231083.Nov 26 2019, 9:00 AM

Added test updates for failing lit tests.

dstuttard updated this revision to Diff 231257.Nov 27 2019, 7:21 AM

Changed the implementation slightly.
Now the isNegatibleForFree includes a bool for allowing multi-use
constants. This is only set to true for calls from getNegatedExpression so it
only allows for the situation where a constant becomes multi-use during
getNegatedExpression recursive evaluation.

This makes all the existing lit tests pass again (with no changes).

First, we can definitely reduce the test - it only needs an fneg(fma(fmul X, C), -C, Y) pattern to show the crash, and that should repro on any target with fma support (so it's just unlucky that we didn't hit this bug sooner).

I thought we could get away with a simpler patch as originally proposed here, but I have convinced myself that would only be sweeping the bug under the rug. In fact, I don't think the current version of this patch goes far enough. When we're rewriting the expression, we can create arbitrary values, so *any* value (not just a constant) could have its number of uses changed and cause a crash/assert from mismatched handling in isNegatibleForFree/getNegatedExpression. I haven't reduced a test for that, but it seems possible.

I'll post an alternate patch that should solve the problem and see what people think of it.

spatel added a comment.EditedDec 3 2019, 12:10 PM

I'll post an alternate patch that should solve the problem and see what people think of it.

D70975

@dstuttard does D70975 cover the original problem motivating this patch?

@dstuttard does D70975 cover the original problem motivating this patch?

Yes - confirmed that the alternative also fixes the issue for me.
I'll abandon this one.

dstuttard abandoned this revision.Dec 10 2019, 2:02 AM

Alternative fix D70975 works.