[X86] AMX programming model.

[LuoYuanke]

Summary

This patch is to implement amx programming model that was discussed in llvm-dev (http://lists.llvm.org/pipermail/llvm-dev/2020-August/144302.html). Thank Hal for the good suggestion in the RA. The fast register allocation is not covered in the patch yet. The patch include:

1. The c interface to end user.
2. The AMX intrinsics in LLVM IR.
3. The Lowering from AMX intrinsics to AMX pseudo instruction.
4. Insert psuedo ldtilecfg and build the def-use between ldtilecfg to amx instructions.
5. The register allocation for tile register.
6. Morph AMX pseudo instruction to AMX real instruction.

We also need support 2 features. That will be implemented in other patches.

1. Support fast register allocation to allocate tile register.
2. Support inline assembly and support allocating the tile register for inline assembly.

Change-Id: I935e1080916ffcb72af54c2c83faa8b2e97d5cb0

[pengfei]

clang/lib/Headers/amxintrin.h

278

The comment is useless.

294

The type is inconsistent with __tile_stored

clang/test/CodeGen/X86/amx_api.c

13 ↗

(On Diff #302738)

Shoud it check for 3 and only 3 llvm.x86.tileloadd64.internal?

llvm/include/llvm/CodeGen/Passes.h

494

Comments?

llvm/include/llvm/CodeGen/TileShapeInfo.h

48

You just need to check
RowImm != InvalidImmShape && ColImm != InvalidImmShape

llvm/lib/Target/X86/X86TileConfig.cpp

118

The format looks strange, I wonder why Lint didn't report it.

llvm/test/CodeGen/X86/statepoint-fixup-invoke.mir

94 ↗

(On Diff #302738)

Is the different caused by the order change of MachineDominator Tree Construction?

[LuoYuanke]

Fix lit test failure.

[akashk4]

It would be great if TILE_RELEASE is supported in the backend, so the scope of transaction is known and the configurations are at least stored to memory properly.

llvm/lib/Target/X86/X86TileConfig.cpp

102

I do not understand why wasn't PSTTILECFG used to store config to memory. I guess it will be difficult to do that because we do not know the scope of a transaction since the TILE_RELEASE is not supported.

[LuoYuanke]

llvm/lib/Target/X86/X86TileConfig.cpp

102

PSTTILECFG is use to store the config from tile config register to memory. Here to need to load the config from memory to tile config register, so that each tile data register is configured.

The LDTIELCFG has been inserted in the X86PreTileConfig pass. Since at X86PreTileConfig pass we don't know the config of the tile physical registers, the shape data in stack slot is zero. At the pass which is after RA, we know the shape of tile registers, so we just fill in the shape in the stack slot.

Do you mean to tile release at the end of each function which use AMX? Since we config tile registers at the beginning of each function that use AMX, it doesn't break AMX operation without tile release. But it may reduce the overhead of thread switch with tile release, if AMX operation in only used for a while in a thread.

[LuoYuanke]

In D87981#2379249, @akashk4 wrote:

It would be great if TILE_RELEASE is supported in the backend, so the scope of transaction is known and the configurations are at least stored to memory properly.

TILERELEASE don't store the config to memory. STTILECFG store the config to memory. Why do we need to store the config to memory?

[LuoYuanke]

clang/test/CodeGen/X86/amx_api.c

13 ↗

(On Diff #302738)

I may create another simple test case that test tile_loadd, tile_dpbsud, __tile_stored seperately.

llvm/test/CodeGen/X86/ipra-reg-usage.ll

6 ↗

(On Diff #301172)

Done at https://reviews.llvm.org/D90810.

llvm/test/CodeGen/X86/statepoint-fixup-invoke.mir

94 ↗

(On Diff #302738)

It seems the test case doesn't ensure the order. I'll take more time to look into the case.

[LuoYuanke]

1. Address Pengfei's comments.
2. Add tilerelease at the epilog.
3. Fix a bug of emitting instruction that use subregister.

[LuoYuanke]

llvm/lib/Target/X86/X86TileConfig.cpp

102

I add tilerelease in function's epilog if the function define AMX registers.

118

I modified the code, but it is reformated by lint again.

[LuoYuanke]

Reformt the code with lint fix.

[LuoYuanke]

Config palette.

[LuoYuanke]

llvm/lib/Target/X86/X86TileConfig.cpp

102

@akashk4, ping

[LuoYuanke]

Rebase.

[LuoYuanke]

Fix clang-tidy.

[LuoYuanke]

llvm/test/CodeGen/X86/statepoint-fixup-invoke.mir

94 ↗

(On Diff #302738)

This is spilled stack slot. The order is sorted by register size. Since the register size of r14 and rbx is the same, so the order is undefined. llvm::sort call std::sort and std::sort doesn't preserve the order of the equivalent elements. (https://stackoverflow.com/questions/4107315/stdsort-behavior-with-ints-that-are-equal)

[LuoYuanke]

Rename type name tile to tile1024i.

[wxiao3]

llvm/include/llvm/CodeGen/LiveRegMatrix.h

44

what's the purpose of this member?

llvm/lib/Target/X86/X86RegisterInfo.cpp

874

Don't need to add PhysReg again if PhysReg is already in Hints.

[wxiao3]

This comment was removed by wxiao3.

[LuoYuanke]

llvm/include/llvm/CodeGen/LiveRegMatrix.h

44

It is useless. Thanks.

llvm/lib/Target/X86/X86RegisterInfo.cpp

874

You are right. I will revise the code.

[LuoYuanke]

Address Wei's comments.

[mehdi_amini]

(Drive by comments)

llvm/include/llvm/CodeGen/TileShapeInfo.h

28

Can you document the class?

llvm/lib/Target/X86/X86PreTileConfig.cpp

30 ↗

(On Diff #305978)

Can you document this as well?

llvm/lib/Target/X86/X86TileConfig.cpp

35

Can you document this pass?

224

Is this usual for MachinePasses to do this? In general the pass manager can display the scheduling when debugging

[LuoYuanke]

llvm/lib/Target/X86/X86TileConfig.cpp

224

Make sense. I'll remove the debug log.

[LuoYuanke]

Address Mehdi's comments.

[rengolin]

You should at least get @craig.topper's feedback, given this is a significant change in the x86 backend.

[LuoYuanke]

In D87981#2405187, @rengolin wrote:

You should at least get @craig.topper's feedback, given this is a significant change in the x86 backend.

We had internal review with Craig on the design before. Craig

In D87981#2405187, @rengolin wrote:

You should at least get @craig.topper's feedback, given this is a significant change in the x86 backend.

We have internal review with Craig and Andy on the design before. Craig may be very busy for now.
@craig.topper
Would you take the time to review my patch?

[craig.topper]

This triggers an assertion in X86LowerAMXType::visit() when compiled with clang test.c -O3

typedef int vec1024 __attribute__((vector_size(1024)));

vec1024 foo(vec1024 x, vec1024 y) {
  return x + y;
}

While deleting: <256 x i32> %x 
Use still stuck around after Def is destroyed:  %add = add <256 x i32> %y, %x
clang-12: llvm/lib/IR/Value.cpp:100: llvm::Value::~Value(): Assertion `materialized_use_empty() && "Uses remain when a value is destroyed!"' failed.

[LuoYuanke]

In D87981#2406530, @craig.topper wrote:

This triggers an assertion in X86LowerAMXType::visit() when compiled with clang test.c -O3

typedef int vec1024 __attribute__((vector_size(1024)));

vec1024 foo(vec1024 x, vec1024 y) {
  return x + y;
}

While deleting: <256 x i32> %x 
Use still stuck around after Def is destroyed:  %add = add <256 x i32> %y, %x
clang-12: llvm/lib/IR/Value.cpp:100: llvm::Value::~Value(): Assertion `materialized_use_empty() && "Uses remain when a value is destroyed!"' failed.

Thank Craig. This case create an instruction "%add = add <256 x i32> %y, %x" which is not covered by the type lowering. So we need do something similar of type legalization for <256 x i32> to split the type. Do you have any suggestion?

[craig.topper]

Remind me what happened with the idea of using a dedicated type for tiles in IR like mmx?

[LuoYuanke]

In D87981#2406777, @craig.topper wrote:

Remind me what happened with the idea of using a dedicated type for tiles in IR like mmx?

Yes, that's good idea. Do you think we need a separate patch to support the new IR type for AMX before this patch? It may be clearer.

[LuoYuanke]

@craig.topper. Thank you for the good idea. I create another patch (https://reviews.llvm.org/D91927) to fix the problem.

[LuoYuanke]

Replace v512i1 with untyped.

[LuoYuanke]

Rebase

[LuoYuanke]

Hi,
I'm going to land the patch if there is no objection.

[pengfei]

LGTM. I think we can land this patch as a beginning. Cheers~