When transform x86_amx load to amx load intrinsics, compiler need
to know the shape the matrix. The shape can be deduced from the user
of the load. However the shape may be defined after the load
instruction, so we need to sink the load to avoid such issue. This patch
only support sink within a basic block.
Details
- Reviewers
craig.topper pengfei xiangzhangllvm akashk4
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/lib/Target/X86/X86LowerAMXType.cpp | ||
---|---|---|
100 | Does this prevent sinking across a call that may change the memory being loaded? |
llvm/lib/Target/X86/X86LowerAMXType.cpp | ||
---|---|---|
100 | Or atomics, or anything with side effects. |
llvm/lib/Target/X86/X86LowerAMXType.cpp | ||
---|---|---|
100 | Thank you for review. Yes. I want to prevent all the scenario that may change the memory being loaded. I'll check how many scenario we need to prevent from sinking. |
llvm/lib/Target/X86/X86LowerAMXType.cpp | ||
---|---|---|
100 | @craig.topper , I do some study, but I still don't understand why load can't sink across atomic instruction or side effect instruction. I notice in MergedLoadStoreMotion::isStoreSinkBarrierInRange(), it only check myThrow() and alias. |
llvm/lib/Target/X86/X86LowerAMXType.cpp | ||
---|---|---|
100 | I only noticed we chain the memory operations during building the DAG and these side effect instructions. Do we have such rules for middle end passes? |
llvm/lib/Target/X86/X86LowerAMXType.cpp | ||
---|---|---|
100 | Doesn't isStoreSinkBarrierInRange call canInstructionRangeModRef not just isnoalias with a range including every instruction between the store and where it wants to be moved to? "Release" ordering for an atomic means that no load/store can be moved below it, for example. |
Does this prevent sinking across a call that may change the memory being loaded?