User Details
- User Since
- Sep 30 2018, 2:53 PM (234 w, 6 d)
Jan 18 2023
Jan 16 2023
Should be fixed already: https://reviews.llvm.org/rG5ab0894fd570b74907255a4e70c716abd1b5063a
Dec 21 2022
Dec 14 2022
Dec 9 2022
Dec 8 2022
Oct 19 2022
This should be covered itself by new test in test/tools/UpdateTestChecks/update_mir_test_checks/.
Oct 18 2022
Sep 22 2022
Aug 29 2022
LGTM, with nit: it's not NFC now, adjust commit title.
Jul 5 2022
Jul 4 2022
Update summary
Jun 30 2022
Jun 29 2022
Jun 27 2022
Jun 15 2022
Jun 14 2022
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