[PATCH] D87981: [X86] AMX programming model prototype.
LuoYuanke via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Thu Nov 12 02:32:14 PST 2020
LuoYuanke added inline comments.
================
Comment at: llvm/test/CodeGen/X86/statepoint-fixup-invoke.mir:94
; CHECK: ADJCALLSTACKDOWN64 0, 0, 0, implicit-def dead $rsp, implicit-def dead $eflags, implicit-def dead $ssp, implicit $rsp, implicit $ssp
- ; CHECK: STATEPOINT 0, 0, 1, @some_call, $rdi, 2, 0, 2, 0, 2, 5, 2, 0, 2, -1, 2, 0, 2, 0, 2, 0, 2, 2, 1, 8, %stack.0, 0, 1, 8, %stack.1, 0, 2, 0, 2, 2, 0, 0, 1, 1, csr_64, implicit-def $rsp, implicit-def $ssp :: (load store 8 on %stack.1), (load store 8 on %stack.0)
+ ; CHECK: STATEPOINT 0, 0, 1, @some_call, $rdi, 2, 0, 2, 0, 2, 5, 2, 0, 2, -1, 2, 0, 2, 0, 2, 0, 2, 2, 1, 8, %stack.0, 0, 1, 8, %stack.1, 0, 2, 0, 2, 2, 0, 0, 1, 1, csr_64, implicit-def $rsp, implicit-def $ssp :: (load store 8 on %stack.0), (load store 8 on %stack.1)
; CHECK-DAG: $r14 = MOV64rm %stack.0, 1, $noreg, 0, $noreg :: (load 8 from %stack.0)
----------------
LuoYuanke wrote:
> pengfei wrote:
> > Is the different caused by the order change of MachineDominator Tree Construction?
> It seems the test case doesn't ensure the order. I'll take more time to look into the case.
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)
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D87981/new/
https://reviews.llvm.org/D87981
More information about the cfe-commits
mailing list