Track data dependencies in SOACs #2006
Conversation
map test correctly reduces the number of binary operations, while scan test does not. Still the dependencies produced by `opDependencies` are very similar.
|
I have a suggestion. Instead of exporting that essentially handles lambdas like you to explicitly in |
|
That works well. Do you have any clue as to why unused operations (adds) are eliminated for map and reduce tests, but not for the scan test? I'm printing the dependencies at various places and they appear to be similar for map and scan. The tests are in |
|
The operator in the scan test is more complicated than the one for the reduce test. Are you sure it works for reductions? |
|
Oh, but the actual reason is that the removal of dead reduction results is by the dedicated rule |
of operation result with current set of dependencies. Need to: 1. Check that reduce dependencies are satisfactory. 2. Actually add a test to scatter0.fut.
Only issue419.fut hits this case. (Perhaps there will be more once the IR/GPU IR/SegOp implementations of opDependencies are less naive---they just use freeIn atm.)
Need to add dedicated test case.
|
Should JVP and VJP be handled in |
|
Yes, they should. I'll review this PR this week. |
| @@ -27,6 +33,23 @@ dataDependencies' :: | |||
| Dependencies | |||
| dataDependencies' startdeps = foldl grow startdeps . bodyStms | |||
| where | |||
| grow deps (Let pat _ (WithAcc inputs lam)) = | |||
| let input_deps = map (mconcat . depsOfWithAccInput) inputs | |||
|
I cannot reproduce the failing tests for issue456.fut locally, but will have a look at the dependencies being generated manually. But I don't get why they would fail now and not before. |
|
I will also take a look. It's possible that your change is not a fault, but simply reveals a bug in some other simplification. |
|
Ok, I'll leave it for now. The dependencies are as I would expect for the standard and multicore pipelines. I couldn't produce any differences between main branch and this branch by adding tests to the program. The IR after the standard pipeline is different, but looks correct to me. (However, I guess the error occurs in one of the simplify passes in the multicure/ispc/wasm pipelines, so that may be irrelevant.) |
|
I also cannot reproduce locally. Hypothesis: the error only occurs after you merge |
|
I found a fix for the real bug this uncovered, but the reason it happens is that the data dependency analysis is now smart(?) enough that we simplify away the kind of manual double buffering that Cosmin is fond of. I guess he'll find out the hard way! |
No description provided.