[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