Roman Lebedev
95848ea101
[Value][InstCombine] Fix one-use checks in PHI-of-op -> Op-of-PHI[s] transforms to be one-user checks
...
As FIXME said, they really should be checking for a single user,
not use, so let's do that. It is not *that* unusual to have
the same value as incoming value in a PHI node, not unlike
how a PHI may have the same incoming basic block more than once.
There isn't a nice way to do that, Value::users() isn't uniqified,
and Value only tracks it's uses, not Users, so the check is
potentially costly since it does indeed potentially involes
traversing the entire use list of a value.
2020-08-26 20:20:41 +03:00
Roman Lebedev
8bfe46dce2
[NFC][InstCombine] Add tests with PHI-of-{insert,extract}value with multiple uses
...
It is fine if the operation has multiple uses, as long as they are all
in this very PHI node.
2020-08-26 20:20:41 +03:00
Roman Lebedev
cdd339c568
[InstCombine] PHI-of-insertvalues -> insertvalue-of-PHI's
...
As per statistic, this happens pretty exceedingly rare,
but i have seen it in exactly the situations the
Phi-aware aggregate reconstruction would have handled,
eventually, and allowed invoke -> call fold later on.
So while this might be something that other fold
will have to learn about, i believe we should be
doing this transform in general.
Here, we are okay with adding two PHI's to get both the base aggregate,
and the inserted value. I'm not sure it makes much sense to restrict
it to a single phi (to just the inserted value?), because originally
we'd be receiving the final aggregate already..
llvm test-suite + RawSpeed:
```
| statistic name | baseline | proposed | Δ | % | \|%\| |
|--------------------------------------------|-----------|-----------|-----:|-------:|------:|
| instcombine.NumPHIsOfInsertValues | 0 | 12 | 12 | 0.00% | 0.00% |
| asm-printer.EmittedInsts | 8926643 | 8926595 | -48 | 0.00% | 0.00% |
| instcombine.NumCombined | 3846614 | 3846640 | 26 | 0.00% | 0.00% |
| instcombine.NumConstProp | 24302 | 24293 | -9 | -0.04% | 0.04% |
| instcombine.NumDeadInst | 1620140 | 1620112 | -28 | 0.00% | 0.00% |
| instcount.NumBrInst | 898466 | 898464 | -2 | 0.00% | 0.00% |
| instcount.NumCallInst | 1760819 | 1760875 | 56 | 0.00% | 0.00% |
| instcount.NumExtractValueInst | 45659 | 45649 | -10 | -0.02% | 0.02% |
| instcount.NumInsertValueInst | 4991 | 4981 | -10 | -0.20% | 0.20% |
| instcount.NumIntToPtrInst | 27084 | 27087 | 3 | 0.01% | 0.01% |
| instcount.NumPHIInst | 371435 | 371429 | -6 | 0.00% | 0.00% |
| instcount.NumStoreInst | 906011 | 906019 | 8 | 0.00% | 0.00% |
| instcount.TotalBlocks | 1105520 | 1105518 | -2 | 0.00% | 0.00% |
| instcount.TotalInsts | 9795737 | 9795776 | 39 | 0.00% | 0.00% |
| simplifycfg.NumInvokes | 2784 | 2786 | 2 | 0.07% | 0.07% |
| simplifycfg.NumSimpl | 1001840 | 1001850 | 10 | 0.00% | 0.00% |
| simplifycfg.NumSinkCommonInstrs | 15174 | 15170 | -4 | -0.03% | 0.03% |
```
Reviewed By: spatel
Differential Revision: https://reviews.llvm.org/D86306
2020-08-25 10:38:11 +03:00
Roman Lebedev
4dec8ec33d
[NFC][InstCombine] Multi-level aggregate test for phi-of-insertvalue pattern
...
See https://reviews.llvm.org/D86306
2020-08-24 22:39:34 +03:00
Roman Lebedev
ea2e682cc2
[NFC][InstCombine] Tests for PHI-of-insertvalue's
...
Currently we don't do anything about these,
neither in InstCombine, nor in SimplifyCFG's sinking.
These happen exceedingly rarely, but i've seen them in the cases where
PHI-aware aggregate reconstruction would have fired if not for them.
2020-08-20 20:16:31 +03:00