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
Paths
| Differential D70595
[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 Change-Id: Iffd1ce18bf13ec68d91ff47aecd7cf1918fd3c0a
Diff Detail
Event Timelinelebedev.ri added inline comments.
dstuttard marked an inline comment as done. Comment ActionsAdded @RKSimon to review as the last major modifier of the code here. Comment Actions 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.
Comment Actions 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. Comment Actions
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. Comment Actions 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. Comment Actions Changed the implementation slightly. This makes all the existing lit tests pass again (with no changes). Comment Actions 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. Comment Actions
Comment Actions
Yes - confirmed that the alternative also fixes the issue for me.
Revision Contents
Diff 231257 llvm/include/llvm/CodeGen/TargetLowering.h
llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp
llvm/lib/CodeGen/SelectionDAG/TargetLowering.cpp
llvm/lib/Target/X86/X86ISelLowering.h
llvm/lib/Target/X86/X86ISelLowering.cpp
llvm/test/CodeGen/AMDGPU/const-multiuse-tl.ll
|
This test doesn't actually check anything.