[all-commits] [llvm/llvm-project] ebf3b1: [Scheduling] Implement a new way to cluster loads/...
QingShan Zhang via All-commits
all-commits at lists.llvm.org
Wed Aug 26 05:34:22 PDT 2020
Branch: refs/heads/master
Home: https://github.com/llvm/llvm-project
Commit: ebf3b188c6edcce7e90ddcacbe7c51c90d95b0ac
https://github.com/llvm/llvm-project/commit/ebf3b188c6edcce7e90ddcacbe7c51c90d95b0ac
Author: QingShan Zhang <qshanz at cn.ibm.com>
Date: 2020-08-26 (Wed, 26 Aug 2020)
Changed paths:
M llvm/include/llvm/CodeGen/ScheduleDAGInstrs.h
M llvm/lib/CodeGen/MachineScheduler.cpp
M llvm/test/CodeGen/AArch64/aarch64-stp-cluster.ll
M llvm/test/CodeGen/AMDGPU/callee-special-input-vgprs.ll
M llvm/test/CodeGen/AMDGPU/max.i16.ll
M llvm/test/CodeGen/AMDGPU/stack-realign.ll
Log Message:
-----------
[Scheduling] Implement a new way to cluster loads/stores
Before calling target hook to determine if two loads/stores are clusterable,
we put them into different groups to avoid fake cluster due to dependency.
For now, we are putting the loads/stores into the same group if they have
the same predecessor. We assume that, if two loads/stores have the same
predecessor, it is likely that, they didn't have dependency for each other.
However, one SUnit might have several predecessors and for now, we just
pick up the first predecessor that has non-data/non-artificial dependency,
which is too arbitrary. And we are struggling to fix it.
So, I am proposing some better implementation.
1. Collect all the loads/stores that has memory info first to reduce the complexity.
2. Sort these loads/stores so that we can stop the seeking as early as possible.
3. For each load/store, seeking for the first non-dependency instruction with the
sorted order, and check if they can cluster or not.
Reviewed By: Jay Foad
Differential Revision: https://reviews.llvm.org/D85517
More information about the All-commits
mailing list