Just a rebase

Address buildfail in https://lab.llvm.org/buildbot#builders/77/builds/5053

It seems there is buildfail, I will revert it and fix bugs.
https://lab.llvm.org/buildbot#builders/77/builds/5053

Address Pengfei's comments

Rebase after https://reviews.llvm.org/D98773 is merged.

address Pengfei's comments

In D93594#2628497, @nikic wrote:

It looks like this has caused a compile-time regression at O0: https://llvm-compile-time-tracker.com/compare.php?from=9341bcbdc93a251b632ffaa51a84452a7a4a5e4e&to=4f198b0c27b04e830a3069aaf4b39cf203eaae4a&stat=instructions

The cause is probably the computation of DomTree and LoopInfo, even if no AMX intrinsics are present. I think you should be able to easily fix this by not fetching DT/LI from the pass manager, and computing them in the pass instead (only if intrinsics are present).

just do a rebase

Fix buildfail when it is -DBUILD_SHARED_LIBS=ON

In D93594#2606157, @RKSimon wrote:

@yubing I've reverted this as it was failing on a lot of buildbots: http://lab.llvm.org:8011/#/builders/109/builds/9867

Thanks all for reporting and reverting this. I will do bugfix asap.

Address pengfei's comments

address comments above

Fix some comments and commit message

Modify some comments

Fix incorrect naming for dpbf16's bb

Rebase and add a testcase.

Do we need to force opt to build a legacypassmanager for this pass?

Address comments above

Address comments above and refactor some code

Small fix for some code

Address the commments above.

Strange. llvm/test/CodeGen/X86/AMX/amx-low-intrinsics.ll can pass in my local machine.

Rebase and add a testcase for dpbf16ps intrinsic.

Rebase and fix the bug in amx_api.c

Fix some bugs in lowerTileDPBSSD, lowerTileStore, lowerTileLoad

No regression appeared in our internal testcases.
It seems the transform is correct, have you verified it with alive-tv?

In D93610#2467210, @craig.topper wrote:

LGTM

In D93610#2466389, @craig.topper wrote:

In D93610#2465689, @yubing wrote:

In D93610#2465382, @craig.topper wrote:

In D93610#2465300, @yubing wrote:

In D93610#2465295, @craig.topper wrote:

Fix WidenVecOp_MSCATTER as well?

May should just take the element type from the original memory VT and the element count from result? Other targets have extending gathers I think which I think would have different element sizes between result and memory?

Yeah, Besides If OpNo == 4 in WidenVecOp_MSCATTER, I guess we shouldn't widen MemType since we only widen the index?

I think we should keep the same number of elements in the memory VT as the operands so I think it should be widened.

I'm starting to wonder if the real mistake was making memory VT a vector for gather/scatter. Maybe it should have just been a scalar for the element type?

Besides, do we use the information of MemType after LegalizeType procedure? I found X86InstrFragmentsSIMD.td may use it that info but mgather is handled outside X86DAGToDAGISel::SelectCode.

X86 doesn't use it, but a target the support extending gather would need the memory VT to figure out how much it extends.

In D93610#2465382, @craig.topper wrote:

In D93610#2465300, @yubing wrote:

In D93610#2465295, @craig.topper wrote:

Fix WidenVecOp_MSCATTER as well?

May should just take the element type from the original memory VT and the element count from result? Other targets have extending gathers I think which I think would have different element sizes between result and memory?

Yeah, Besides If OpNo == 4 in WidenVecOp_MSCATTER, I guess we shouldn't widen MemType since we only widen the index?

I think we should keep the same number of elements in the memory VT as the operands so I think it should be widened.

I'm starting to wonder if the real mistake was making memory VT a vector for gather/scatter. Maybe it should have just been a scalar for the element type?

Modify code according to Craig's comments

In D93610#2465295, @craig.topper wrote:

Fix WidenVecOp_MSCATTER as well?

May should just take the element type from the original memory VT and the element count from result? Other targets have extending gathers I think which I think would have different element sizes between result and memory?

In D92645#2459005, @craig.topper wrote:

I think this looks good to me. What about you @yubing?

PING?

Modified some code according Pengfei's comments

In D92548#2430468, @sdesmalen wrote:

Thanks for finding and fixing this!

Can the test be simplified by using <4 x float> instead of <48 x float>?

Modified some code according to comments

Delete some useles code