[all-commits] [llvm/llvm-project] e0c382: [AMDGPU] Limit runs of fixLdsBranchVmemWARHazard

Piotr Sobczak via All-commits all-commits at lists.llvm.org
Mon Jun 14 13:31:13 PDT 2021


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: e0c382a9d5a0e2689b97186736ebc82e17c5f822
      https://github.com/llvm/llvm-project/commit/e0c382a9d5a0e2689b97186736ebc82e17c5f822
  Author: Piotr Sobczak <Piotr.Sobczak at amd.com>
  Date:   2021-06-14 (Mon, 14 Jun 2021)

  Changed paths:
    M llvm/lib/Target/AMDGPU/GCNHazardRecognizer.cpp
    M llvm/lib/Target/AMDGPU/GCNHazardRecognizer.h

  Log Message:
  -----------
  [AMDGPU] Limit runs of fixLdsBranchVmemWARHazard

The code in fixLdsBranchVmemWARHazard looks for patterns of a vmem/lds
access followed by a branch, followed by an lds/vmem access.

The handling of the hazard requires an arbitrary number of instructions
to process. In the worst case where a function has a vmem access, but no lds
accesses, all instructions are examined only to conclude that the hazard
cannot occur.

Add the pre-processing stage which detects if there is both lds and vmem
present in the function and only then does the more costly search.

This patch significantly improves compilation time in the cases the hazard
cannot happen. In one pathological case I looked at IsHazardInst is needlesly
called 88.6 milions times.

The numbers could also be improved by introducing a map around the
inner calls to ::getWaitStatesSince in fixLdsBranchVmemWARHazard, but
nothing will beat not running fixLdsBranchVmemWARHazard at all in the cases
detected by shouldRunLdsBranchVmemWARHazardFixup().

Differential Revision: https://reviews.llvm.org/D104219




More information about the All-commits mailing list