User Details
- User Since
- Sep 30 2018, 2:53 PM (196 w, 3 d)
Tue, Jul 5
Mon, Jul 4
Update summary
Thu, Jun 30
Wed, Jun 29
Mon, Jun 27
Wed, Jun 15
Tue, Jun 14
Please rebase against precommited tests.
Please rebase against precommited tests.
May 14 2022
Mar 22 2022
This is already closed, reopened accidentally.
Mar 19 2022
Abandoning this. PR52275 was solved by D119679 and following patches.
Feb 25 2022
Feb 24 2022
Fix sanitizer breakage: erase phi-nodes from InstInfoMap before erasing themselves
Feb 23 2022
I'm to backport this: https://github.com/llvm/llvm-project/issues/54013
@lebedev.ri Ping. Is it ok now?
Feb 21 2022
This is a partial revert of rG954ea0f044e0. It looks like there is still an issue with cost computation here, but I'm to fix it in a separate patch and to backport both patches to 14.0.0. Therefore looks good to me. Add @ABataev.
Feb 16 2022
LGTM
Feb 15 2022
Feb 14 2022
Add test
Add comment
Are there tests with switches, where the PHI node has multiple incoming edges from the same predecessor?
What do you mean by "the same predecessor"? There is test with ordinary loop.
Address comments
Feb 13 2022
Interpret insertelements with undef/uncorrect/non-constant index as initial vector
Well, that would definitely solve the problem. There is also another way: on the contrary, remove hasOneUse() check from vectorizeInsertElementInst. This patch allows it.
Yes, sure, but it will require some extra stuff and some time to polish and fix all corner cases. If we’d like to fix it in 14.0, better to start with a simple fix and then try to implement more complex feature.
Ok, got it. Could you also add a check to the buildvector detection function for such kind of insertelement (+ possibly insertvalue) instructions? They should not be treated as a part of buildvector, need to treat them as an initial/terminating instruction and exclude from possibly vectorizable buildvector instructions.
No, they doesn't apply cleanly right now, but I'm to backport them through new workflow (https://discourse.llvm.org/t/rfc-new-automated-release-workflow-part-2/59981)
Feb 12 2022
Fix rebase
Address some comments, rebase against D119623
Feb 11 2022
Make a separate NFC patch for default parameter of getInsertIndex
Feb 8 2022
I've investigated small regressions, caused by this patch. The sizes are actually increased at the backend level, while translating llvm to machine code, for instanse:
> ll symtab.c.* 13769 symtab.c.base.ll 13681 symtab.c.exp.ll 8280 symtab.c.base.s 8394 symtab.c.exp.s
For the tests from testsuite this mostly leads to just +16 bytes code size increase (see table at D109817#3184752), so I believe it's acceptable fluctuation.
Feb 7 2022
Rebase
Jan 17 2022
Dec 12 2021
Dec 10 2021
Dec 4 2021
Update tests
Dec 1 2021
Nov 22 2021
Btw, the only impact seen by this patch is almost zero, the test suite shows three size-reduced tests and no regressions:
$ ~/llvm/test-suite/utils/compare.py -a --filter-short -m size..text result_base.json vs result_exp.json ... test-suite...abench/jpeg/jpeg-6a/cjpeg.test 167826.00 167810.00 -0.0% test-suite...nsumer-jpeg/consumer-jpeg.test 167186.00 167170.00 -0.0% test-suite...lications/sqlite3/sqlite3.test 496674.00 496546.00 -0.0%
Bu general recollection is that the order is intentional
to avoid pattern disturbance by instcombine before AIC has a chance.
Hmm, it would be great to see an example. I've seen the reverse cases for now: disturbance by AIC before IC.
Nov 15 2021
Nov 14 2021
There is no cost difference, just the tests are crashing.
Ok, I see, so add such test to this commit?
Add test showing different costs?
Nov 13 2021
Nov 12 2021
Thanks for digging that up. I don't see any reason that it was placed that way either, so LGTM. Please wait to see if @lebedev.ri agrees though.
Ping @lebedev.ri .