[AMDGPU] Limit runs of fixLdsBranchVmemWARHazard
authorPiotr Sobczak <Piotr.Sobczak@amd.com>
Mon, 14 Jun 2021 10:17:35 +0000 (12:17 +0200)
committerPiotr Sobczak <Piotr.Sobczak@amd.com>
Mon, 14 Jun 2021 20:30:23 +0000 (22:30 +0200)
commite0c382a9d5a0e2689b97186736ebc82e17c5f822
tree736570d0863579d1f68303e496469e3a99e0610f
parentecb68f1c8b11b54dc8c48af9f5fe28c261090aba
[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
llvm/lib/Target/AMDGPU/GCNHazardRecognizer.cpp
llvm/lib/Target/AMDGPU/GCNHazardRecognizer.h