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

Stanislav Mekhanoshin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Sat Jan 19 00:18:05 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;
+
----------------
rampitec wrote:
> 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.
It is wrong NOT to call it of course.


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

https://reviews.llvm.org/D56923





More information about the llvm-commits mailing list