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