|
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6 |
|
| #
1650f1b3 |
| 15-May-2024 |
Jay Foad <jay.foad@amd.com> |
Fix typo "indicies" (#92232)
|
|
Revision tags: llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1 |
|
| #
acdc419c |
| 04-Feb-2022 |
Bjorn Pettersson <bjorn.a.pettersson@ericsson.com> |
[test] Use -passes=instcombine instead of -instcombine in lots of tests. NFC
Another step moving away from the deprecated syntax of specifying
pass pipeline in opt.
Differential Revision: https://r
[test] Use -passes=instcombine instead of -instcombine in lots of tests. NFC
Another step moving away from the deprecated syntax of specifying
pass pipeline in opt.
Differential Revision: https://reviews.llvm.org/D119081
show more ...
|
|
Revision tags: llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3 |
|
| #
95848ea1 |
| 26-Aug-2020 |
Roman Lebedev <lebedev.ri@gmail.com> |
[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 i
[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.
show more ...
|
| #
8bfe46dc |
| 26-Aug-2020 |
Roman Lebedev <lebedev.ri@gmail.com> |
[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.
|
| #
cdd339c5 |
| 25-Aug-2020 |
Roman Lebedev <lebedev.ri@gmail.com> |
[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
[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
show more ...
|
| #
4dec8ec3 |
| 24-Aug-2020 |
Roman Lebedev <lebedev.ri@gmail.com> |
[NFC][InstCombine] Multi-level aggregate test for phi-of-insertvalue pattern
See https://reviews.llvm.org/D86306
|
|
Revision tags: llvmorg-11.0.0-rc2 |
|
| #
ea2e682c |
| 20-Aug-2020 |
Roman Lebedev <lebedev.ri@gmail.com> |
[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 the
[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.
show more ...
|