handling method calls in HSAIL

Venkatachalam, Vasanth Vasanth.Venkatachalam at amd.com
Wed Jul 10 08:55:11 PDT 2013


While implementing support for function calls in the HSAIL backend, we identified some ways of tackling common problems that both HSAIL and PTX backends may face. We wanted to describe our ideas and see what people think.

1)      In the same HSAIL kernel, A calls B multiple times from different places in its code, and we want to avoid compiling B more than once.

2)      In the same HSAIL kernel, A calls B, A calls C, and C calls B. Here again, we want to avoid compiling B more than once.

3)      Multiple HSAIL kernels call the same method.

To tackle 1) and 2), we're thinking of defining a HashMap<ResolvedJavaMethod, Boolean> in HSAILCompilationResult which keeps track of all methods called by a single HSAIL kernel (and any methods it calls) and whether they have been compiled. Whenever the LIR triggers the creation of a direct call node (via call to HSAILLIRGenerator.emitDirectCall), we check whether a reference to the called method already exists in this Hashmap (which is global to a single HSAIL kernel), and if not, we add it and set a flag that indicates that the method needs to be compiled.

We then modify getHSAILCompilationResult so that after compiling the body of the current method, we process the above Hashmap to see which methods have not been compiled yet and compile those methods thru recursive calls to getCompilationResult().

It sounds like this should get around 1) and 2, but for 3) we would need a data structure that's global to all kernels. We're still scoping out what that should be.

We've implemented this approach in our local branch (not yet checked in) and are testing it, but wanted to see what people think.
Do folks have other ideas for tackling 1) and 2) that would be more efficient?


More information about the graal-dev mailing list