Current upstream crash with test attached.

Thanks guys for the feedback!
Addressed review comments.

Thanks Sanjay for the review!
Addressed review comments.

I don't think that's the intention of this specific test given the name insert_extract_element_same_vec_idx_2. And also the unused parameter %a.
This is failing due after a local change to instsimplify and I think the test maybe isn't testing what it wants to test?

why do we need this change?
insert element into undef is common to construct a vector, being fixed or scalable.

Thanks @paulwalker-arm for the review!
I have moved the new tests into sve-masked-ldst-nonext.ll in the commit.

Hey @fpetrogalli @sdesmalen , any updates on this patch? This should be the last one to commit for structure load? Or are we using different approach?

Thanks Eli for pointing this out!

In D78267#2025884, @thakis wrote:

Looks like this breaks check-llvm at least on Linux: http://45.33.8.238/linux/17186/step_12.txt

Can you take a look? If it takes a while to fix, please revert while you investigate.

Thanks! Fixed in the committed patch.

Address review comments.

Address review comments.

Thanks Eli for the feedback!
Please let me know if the fixes related to shuffle vector make sense to you.

Rebase.

Thanks Sander for the feedback!

1. Current upstream crash at:

llvm::ShuffleVectorInst::ShuffleVectorInst(llvm::Value *, llvm::Value *, ArrayRef<int>, const llvm::Twine &, llvm::Instruction *): Assertion `isValidOperands(V1, V2, Mask) && "Invalid shuffle vector instruction operands!"' failed.
take test.ll , run opt -S -instcombine test.ll

Looks fine with me.

I am also looking at the related issues of shufflevector created by "extractelement, insertelement" pair.
Currently working on InstCombiner::visitInsertElementInst.

Thanks Eli for the feedback!

Current upstream crash at llvm/include/llvm/ADT/APInt.h:1437: void llvm::APInt::setBit(unsigned int): Assertion `BitPosition < BitWidth && "BitPosition out of range"' failed.

My initial thought was wrong.
Spent sometime look again, we are nearly impossible to generate incorrect result without the code fixes in this patch.
But comparing a scalable size with a fixed size still doesn't make sense.

Thanks Eli for the feedbacks!
Yes, it's valid to use scalable type mininal size for inbounds checking.

Current upstream crash at llvm/lib/IR/Constants.cpp:1674: static llvm::Constant *llvm::ConstantExpr::getCast(unsigned int, llvm::Constant *, llvm::Type *, bool): Assertion `CastInst::castIsValid(opc, C, Ty) && "Invalid constantexpr cast!"' failed.

Address review comments.

Address review comments.

Current upstream is producing wrong AliasResult for scalable type.

Take test.ll, run opt -S -instsimplify -o -
Then you will get the compiler warning: Compiler has made implicit assumption that TypeSize is not scalable.

Address review comments.

Address review comments.

minor update test name