1 
 2 ### Refactor the existing code for closing over kernel+compute call chains with ModuleOp
 3 ----
 4 
 5 * [Contents](hat-00.md)
 6 * House Keeping
 7     * [Project Layout](hat-01-01-project-layout.md)
 8     * [Building Babylon](hat-01-02-building-babylon.md)
 9     * [Building HAT](hat-01-03-building-hat.md)
10 * Programming Model
11     * [Programming Model](hat-03-programming-model.md)
12 * Interface Mapping
13     * [Interface Mapping Overview](hat-04-01-interface-mapping.md)
14     * [Cascade Interface Mapping](hat-04-02-cascade-interface-mapping.md)
15 * Implementation Detail
16     * [Walkthrough Of Accelerator.compute()](hat-accelerator-compute.md)
17     * [How we minimize buffer transfers](hat-minimizing-buffer-transfers.md)
18 
19 ----
20 
21 At present, we take the CodeModel (FuncOp rooted tree) of the kernel entrypoint, traverse it to
22 locate calls. We recursively traverse those calls and end up closing over the complete 'graph' of reachable calls.
23 
24 We have a test case which demonstrates a much more elegant way of doing this and exposing the whole 'closure' as a ModuleOp.
25 
26 See [test/jdk/java/lang/reflect/code/TestTransitiveInvokeModule.java](https://github.com/openjdk/babylon/blob/code-reflection/test/jdk/java/lang/reflect/code/TestTransitiveInvokeModule.java)
27 
28 In my defen[sc]e ;) The hat code predated ModuleOp...
29 
30 So this task would involve taking the test code for generating this closure and use it rather than
31 the clunky existing version.
32 
33 
34 See [hat/core/src/main/java/hat/callgraph/CallGraph.java](https://github.com/openjdk/babylon/blob/code-reflection/hat/core/src/main/java/hat/callgraph/CallGraph.java)
35 
36 And other code in [hat/core/src/main/java/hat/callgraph](https://github.com/openjdk/babylon/tree/code-reflection/hat/core/src/main/java/hat/callgraph)
37 
38 The existing HAT code does also do some tests on the code (especially kernel code) to determine if the model is valid. We
39 
40 We check for allocations, exceptions, we assert that all method parameters are mapped byte buffers or primitives.
41 
42 There are other checks which we might add BTW.
43 
44 As a followup to this 'chore' .. For bonus points as it were
45 
46 Me might Consider inlining trivial methods (the life `var()` example above is an interesting candidate ;)
47 
48 We need to determine which buffers are mutated or just accessed from the kernel call graph.
49 This is especially important for minimising buffer transfers.
50 I planned to do this when I implemented the prototype, but it was tougher than I first thought.
51 
52 Tracing buffer aliasing across calls hurt my head a little.
53 
54 At present, we rely on annotations @RO,@RW and @WO on kernel args (and trust them) we might still need these for
55 compute calls which are not code reflectable. But we should not need them for kernel graphs.
56 
57 
58