[PATCH] D56923: [AMDGPU] Fixed hazard recognizer to walk predecessors

Stanislav Mekhanoshin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 18 12:21:03 PST 2019


rampitec marked an inline comment as done.
rampitec added inline comments.


================
Comment at: lib/Target/AMDGPU/GCNHazardRecognizer.h:34-35
 class GCNHazardRecognizer final : public ScheduleHazardRecognizer {
+  // Distinguish if we are called from scheduler or hazard recognizer
+  bool IsHazardRecognizerMode;
+
----------------
arsenm wrote:
> I'm surprised this is necessary. To clarify did you somehow only see these problems with -O0? As far as I know we don't run the standalone hazard recognizer when the scheduler is in use, so you should end up with the same issues either way.
The problem exists regardless of the optimization level.
We do run standalone recognizer even when scheduler is in use. We add it from GCNPassConfig::addPreEmitPass().
In fact that is wrong to call it regardless of the scheduler, as scheduler sends regions in a bottom-up order. To ensure all hazards are correctly checked a target must run standalone recognizer, there is even a comment there about it.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56923/new/

https://reviews.llvm.org/D56923





More information about the llvm-commits mailing list