Should be fixed already: https://reviews.llvm.org/rG5ab0894fd570b74907255a4e70c716abd1b5063a

This should be covered itself by new test in test/tools/UpdateTestChecks/update_mir_test_checks/.

LGTM, with nit: it's not NFC now, adjust commit title.

In D129065#3631052, @jrtc27 wrote:

Commit subject/body should say C++ in it

Update summary

In D128625#3621030, @MaskRay wrote:

The description seems unclear to me. Is a riscv64-unknown-linux-gnu GCC installation selected while the requested target triple is riscv64-unknown-elf?

Please rebase against precommited tests.

Please rebase against precommited tests.

In D122233#3513581, @RKSimon wrote:

FWIW we might be able to perform something similar inside VectorCombine

In D122233#3399664, @lebedev.ri wrote:

Do we expect that unused inputs of the shuffle has been already replaced with undef?

This is already closed, reopened accidentally.

Abandoning this. PR52275 was solved by D119679 and following patches.

In D109817#3344942, @lebedev.ri wrote:

In D109817#3344766, @anton-afanasyev wrote:

Fix sanitizer breakage: erase phi-nodes from InstInfoMap before erasing themselves

(If you believe that fixes the issue then feel free to recommit, no further feedback here expected)

Fix sanitizer breakage: erase phi-nodes from InstInfoMap before erasing themselves

I'm to backport this: https://github.com/llvm/llvm-project/issues/54013

@lebedev.ri Ping. Is it ok now?

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.

LGTM

Add test

In D109817#3320059, @lebedev.ri wrote:

In D109817#3319994, @anton-afanasyev wrote:

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.

https://godbolt.org/z/MdsrzGnvq

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

In D119623#3318056, @ABataev wrote:

Would be good to test it using test suite at least, just in case we missed something.

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.

In D119623#3316685, @RKSimon wrote:

Something to take it account with this and D119536 - we're going to need to cherrypick these fixes for PR52275 as they affect 14.x as well - will they be able to apply cleanly to the 14.x branch?

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)

In D119623#3316827, @ABataev wrote:

What kind of bugs do you see with these test cases and current version of the function? I would try to keep it, better to generate UndefMaskElem if possible, rather than cut of the vectorization early.

Fix rebase

In D119536#3314640, @ABataev wrote:

Hmm, looks like the problem appears only if we have insertelements to be vectorized not from vectorizeInsertElementInst, where we have a proper check. Maybe just add a check for insertelements in other functions and just expect them from vectorizeInsertElementInst?

Address some comments, rebase against D119623

Make a separate NFC patch for default parameter of getInsertIndex