-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[async] More SFG optimizations #1877
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1877 +/- ##
==========================================
+ Coverage 43.25% 44.21% +0.95%
==========================================
Files 44 44
Lines 6320 6111 -209
Branches 1092 1092
==========================================
- Hits 2734 2702 -32
+ Misses 3416 3240 -176
+ Partials 170 169 -1
Continue to review full report at Codecov.
|
04cddb4
to
fb77de7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great!! LGTMig.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the delay, I'm still catching up this part, so please feel free to merge! I left a question on the activation demotion..
continue; | ||
|
||
auto list_node = *node->input_edges[list_state].begin(); | ||
tasks[std::make_pair(node->rec.ir_handle, list_node)].push_back(node); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to confirm, if there's such a launch sequence:
@ti.kernel
def foo():
for i in x:
y[i] = ...
@ti.kernel
def bar():
for i in range(...):
if some_cond(i):
x[i] = ... # potentially changes x's mask/list state
foo()
bar()
foo() # <-- cannot demote the activation of |y| now
Does this not demote activation as expected?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe the things will go as expected (although not tested). The second foo()
uses a different list of x
, and activation demotion will only happen when the same list states are used :-)
(Btw we should set up a testing system so that cases like this can be tested...)
Related issue = #742
List of changes:
misc/async_mgpcg.py
, which is a fully asynchronous MGPCG. Note that the old MGPCG has Python-scope operations such asbeta = sum[None]
, which force the system to synchronizeStateFlowGraph::optimize_listgen
is re-written. Now theClearListStmt
gets removed together with thelistgen
taskStateFlowGraph::optimize_dead_store
no longer removesClearListStmt
AsyncEngine::synchronize()
no longer dooptimize_listgen
afterfusion
, sinceListGen
with fused serials ofClearList
is not yet supported (TODO: support...)TaskLaunchRecord
now has a uniqueid
. This will be used when generating thedot
files. Having a consistentid
simplified debugging.StateFlowGraph::Node::launch_id
is removed and we display theTaskLaunchRecord
id onlyProgram
now has asnodes
mapping that maps SNode id to SNode pointerStateFlowGraph::extract
now takes abool sort
. Note that sorting an intermediate graph (which doesn't have order independency) can lead to wrong resultsStateFlowGraph::demote_activation
ConstExprPropagation
fordemote_activation
StateFlowGraph::dump_dot
can now visual a state flow chain of a single state only. (TODO: make a standard API? it's harder coded for now. What should the API look like?)[Click here for the format server]