Mehdi has fixed this.

Committed in https://reviews.llvm.org/rGa2e6506c47b1.

Committed in https://reviews.llvm.org/rGa2e6506c47b1.

Could you try this patch? https://reviews.llvm.org/D94607

Thanks for the report, looking into it.

This commit broke compilation of debuginfo-tests/llvm-prettyprinters/gdb/mlir-support.cpp. The compile command for this file doesn't get the path to the tblgen-generated includes, and it fails with

In file included from /w/src/llvm.org/debuginfo-tests/llvm-prettyprinters/gdb/mlir-support.cpp:2:
/w/src/llvm.org/llvm/../mlir/include/mlir/IR/BuiltinTypes.h:638:10: fatal error: 'mlir/IR/BuiltinTypes.h.inc' file not found
#include "mlir/IR/BuiltinTypes.h.inc"
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.

LGTM, Thanks!

Looks great! Thank you for doing this.

LGTM. Thanks!

Sorry, I just noticed this now. Yes, this does make perfect sense. As a matter of fact, I've been thinking of reorganizing the "default mode" to be something that does not need an explicit entry.

Committed in db04bec5f1eeb581ee1470e5f444cc7b918c6d93. Somehow phabricator missed it and didn't close automatically.

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.