Start by pulling out a little chunk of code that FNeg and FSub will share. More to follow...
Details
- Reviewers
spatel kpn arsenm craig.topper andrew.w.kaylor - Commits
- rZORG07c76a405c58: [InstCombine] Add visitFNeg(...) visitor for unary Fneg
rG07c76a405c58: [InstCombine] Add visitFNeg(...) visitor for unary Fneg
rG2557ca296a9b: [InstCombine] Add visitFNeg(...) visitor for unary Fneg
rL361188: [InstCombine] Add visitFNeg(...) visitor for unary Fneg
Diff Detail
- Repository
- rL LLVM
Event Timeline
llvm/lib/Transforms/InstCombine/InstCombineAddSub.cpp | ||
---|---|---|
1828–1829 ↗ | (On Diff #198711) | I'm not confident this one-use check should be here. Though i see that this is only moving it around. The performance concern (the inverse transform, |
llvm/lib/Transforms/InstCombine/InstCombineAddSub.cpp | ||
---|---|---|
1828–1829 ↗ | (On Diff #198711) |
Depends on the architecture really. Worst case, we could end up with a NEG and a MUL, or alternatively 2 MUL's. If a MUL is slower than an XOR (the NEG), then the check would make sense.
That's a good peep. Should probably be handled in a separate Diff though. I'm trying not to modify code here, just replicate FSub xforms for the new FNeg. |
llvm/lib/Transforms/InstCombine/InstCombineAddSub.cpp | ||
---|---|---|
1828–1829 ↗ | (On Diff #198711) | That was D50417. If there are multiple uses, the 2 potential forms would look something like this: T = fdiv X, C R = fneg T vs. T = fdiv X, C R = fdiv X,-C So correct, no difference in instruction count. And I agree that this isn't our usual trade-off in IR/analysis. But I do wonder if the fneg allows for better reassociation opportunities. Not sure how to check that though. I also agree on the codegen/perf concern, but that would have to be added first to the backend IMO to avoid (the theoretical, but potentially large) regression, so I went with the conservative quick fix. I don't think we can get away with an SDAG solution. If those fdivs end up in different basic blocks somehow, we need a global analysis to know the siblings exist. |
Rename CreateWithCopiedFlags(...) argument, since it is no longer strictly a BinaryOperator.
Ping.
Are we okay with addressing the concerns @lebedev.ri brought up in a different patch? I could file a bug if wanted.
LGTM
Are we okay with addressing the concerns @lebedev.ri brought up in a different patch? I could file a bug if wanted.
It's definitely a different patch (if we can actually do anything about it). Adding details from the discussion here to the existing code comment would be good as a separate NFC too.
llvm/lib/Transforms/InstCombine/InstCombineAddSub.cpp | ||
---|---|---|
1824 ↗ | (On Diff #199068) | Would be nice to have a documentation comment for this function that says something like: |
Bah, I forgot to amend my commit message before committing. For posterity's sake, it should have read:
[InstCombine] Create foldFNegIntoConstant(...) helper for FNeg Break out a helper function, namely foldFNegIntoConstant(...), which performs transforms common between visitFNeg(...) and visitFSub(...). Differential Revision: https://reviews.llvm.org/D61693