Following the comment's thread of D117235, I added checks for the widening + splitting case, which also causes a split with one of the resulting vectors to be empty. Due to the same issues described in that same thread, the fixed-vectors-strided-store.ll test is missing the widening + splitting case, while the same case in the strided-vpload.ll test requires to manually split the loaded vector.
Does MemVT for a VP_STRIDED_LOAD ever mismatch with the element count of the result. This GetDependentSplitDestVTs is because of how we widen masked loads, but we aren't doing that same widening for strided loads.
Can the HiIsEmpty case happen?
Doesn't the offset need to include the stride which you can't do just like you can't for scalable vectors.
We're inside of type legalization, why wouldn't the stride type get legalized after the split? Though you wouldn't be able to use it in the ISD::MUL below if you didn't extend it first.
I am using GetDependentSplitDestVTs because I need the HiIsEmpty flag, I do not know if there is a better way to do it though.
I forgot to add the legalization steps for integer operands. I opened a new revision to address this: D123112
I think that in the case that we have a widening followed by a split it may happen that one of the resulting vectors is empty, similar to what happens for VP_LOAD and VP_STORE. But it also may be that I am misunderstanding how the splitting for strided intrinsics should work.
In getStridedLoadVP the MachineMemOperand is created using MemoryLocation::UnknownSize, isn't this correct?
I didn't realize getStridedLoadVP did that. I think I noticed the inconsistency between store and load and thought there was something wrong. I think we should make them consistent.