handling method calls in HSAIL

[Morris Meyer]

Vasanth,

I added a class ExternalCompilationResult recently that could be a good 
place for this sort of functionality.  Could you make use of it for HSAIL?

This was part of changes recently that enabled PTX compiled kernels to 
execute on live Nvida hardware.

         --mm

On 7/10/13, 11:55 AM, Venkatachalam, Vasanth wrote:
> Hi,
>
> 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?
>
> Vasanth
>
>
>
>
>
>