This patch is : reviewed-by: Vincent Lejeunevljn at ovi.com
- Mail original -
De : Tom Stellard t...@stellard.net
À : Vincent Lejeune v...@ovi.com
Cc : mesa-dev@lists.freedesktop.org mesa-dev@lists.freedesktop.org;
llvm-comm...@cs.uiuc.edu llvm-comm...@cs.uiuc.edu; Tom Stellard
Hi Vincent,
Here is an updated patch where I added a call to
SubstituteKCacheBank() in canClauseLocalKillFitInClause() This should
prevent OQAP uses and defs from being split because of constant bank
limitations.
Maybe we can leave the ScheduleDAGMutation optimization as a future
TODO.
-Tom
I have put some comments below but otherwise the patch is
reviewed-by: Vincent Lejeune vljn at ovi.com
-- next part --
From 2eb4673e3184af0e077cbe30a594602441e8d98e Mon Sep 17 00:00:00 2001 From:
Tom Stellard thomas.stellard at amd.com
Date: Thu, 5 Sep 2013 08:59:32
Hi Vincent,
It turns out that it's not possible to correctly schedule uses and defs
of the OQAP register without proper alias analysis in the MachineScheduler. See
the explanation in the lds-output-queue.ll test case.
Here is an updated patch that fixes all the outstanding LDS scheduling
bugs
This patch should work when checking than no OQAP is used before beeing queued,
assuming that a value in OQAP is consumed
and cannot be read twice. However I'm not sure I cover all LDS instructions
that queues a value, I only use LDS_RET_READ in switch case.
Vincent
- Mail original -
Hi Vincent,
Here is an updated patch. I wasn't sure where to put the assertion to
check that UnscheduledNoLiveOut{Defs,Uses} is empty when switching to a
new clause. I tried adding it to R600SchedStartegy::schedNode() behind
the if (NextInstKind != CurInstKind) condition, but it always failed.
From: Tom Stellard thomas.stell...@amd.com
Reading the special OQAP register pops the top value off the LDS
input queue and returns it to the instruction. This queue is
invalidated at the end of an ALU clause and leaving values in the queue
can lead to GPU hangs. This means that if we load a