In D88138#2294257, @aeubanks wrote:

I think I'm still missing how exactly this will fit into the pipeline. As in where is registerPassBuilderCallbacks() going to be called?

In D88138#2294304, @quic_aankit wrote:

My understanding is that this API gives other applications chance to modify the pass pipeline.

You're right, it goes in the other direction. Looks ok to me.

I don't think it's safe to add dead defs to the extra lanes. You could split the superset into the matching part and the remaining part, then only operate on the matching one.

We should probably change bugpoint to stop using undef everywhere.

Fixed in https://reviews.llvm.org/rGe976fb1e54f3.

In D87691#2289933, @kparzysz wrote:

In D87691#2289581, @fhahn wrote:

It would be great if you could take a look or revert if it takes longer to fix.

Sure, let me check.

In D87691#2289581, @fhahn wrote:

It would be great if you could take a look or revert if it takes longer to fix.

Removed unnecessary checks in isSubmask.

Fixed submask detection.

Pre-committed new test file.

Add testcases with unequal masks.

Removed the bool argument to getMatchingValue. Added comments explaining how the return value is used.

Thank you both @srj and @pranavb for your help!

Should be fixed in https://reviews.llvm.org/rG5f4abb7fab1c.

The machine instructions in both dumps are identical... There are differences in addresses that are printed in the dump, and in the names of some values in the LLVM IR, but the machine instructions are the same.

The LLVM ERROR: Do not know how to split the result of this operator! happens when a function with an HVX intrinsic is compiled without +hvx,+hvx-length... attributes.

I added it to attributes #0, #1, #3 and #4.

If you have the ability to pass LLVM options, could you get the good and bad outputs with -debug-only=isel,legalize-types,legalizedag -print-after-all?

Just llc -march=hexagon < bad_hvx64_code.ll, but I added "target-cpu"="hexagonv65" "target-features"="+hvx,+hvx-length64b" to attributes inside the file.

In rG0ee54cf88329c50f25872ac1c67d7ae60ee3154c#946823, @srj wrote:

It may well still be too hard to debug with what I've given you -- let me know if it needs to be simplified further.

Rebased on top of D87691.

Created D87691 with the refactoring. Will rebase this patch soon.

Great, thanks! Will take a look tomorrow.

Do you know what vector types are involved (e.g. <32 x i8>)? Anything with i1 or i64?

This should be NFC for everything that doesn't involve masked loads/stores.

Sure. Keep me posted.

Fix for the crash: D87423.

Addressed comments.

Marked masked-storing intrinsics as write-only in 8b7c8f2c549d301fcea75d8e6e98a8ee160d5ff4.

Calling isMaskedStoreOverwrite from isOverwrite to avoid multiple checks.

I think that the isMaskedStoreOverwrite could be merged into isOverwrite, but it'd need to take instructions in addition to the locations. I think it would be a bit cleaner than what this patch does.

Proposed fix: https://reviews.llvm.org/D87414.

Still investigating. Changing getLocForWriteEx doesn't fix it.

Hopefully https://reviews.llvm.org/rG0ee54cf88329 fixes this.

Yes, it fails to remove the store.

@srj Checking...

I disabled MSSA in this testcase so it won't fail when you switch (db7defd9bab7527ec1d0ed3fc62b379a9adf0971). I'll fix it in the meantime.

Hm, it fails with MemorySSA. Let me figure this out...

@fhahn Sure, let me do it now.

Committed in https://reviews.llvm.org/rG81ff2d30a900. Forgot to update the commit message. :(

Pre-committed a testcase.

Added a testcase for GVN.