trying to compile filter().forEach() for HSAIL

[Doug Simon]

On Oct 14, 2014, at 11:19 PM, Eric Caspole <eric.caspole at amd.com> wrote:

> I am trying to offload a multi-step stream of lambdas with Sumatra, where I would compile both the filter and the forEach into 1 kernel.
> 
> Here is my test code I want to offload:
> 
>        MyPoint[] inputs;
>        int[] data;
>        int[] data2;
> 
>        Arrays.stream(inputs).
>                parallel().
>                filter(p -> ((p.x > 6) && (data2 != null))).
>                forEach(p -> {
>                    p.y = data[p.x] + data2[p.x];
>                });
> 
> I am trying to do it by using a helper method that will become the "main" of the kernel so to speak:
> 
>    public static final <S> void accept(Predicate<S> predicate,
>            Consumer<S> forEachConsumer,
>            S iterationVariable) {
>        if (predicate.test(iterationVariable)) {
>            forEachConsumer.accept(iterationVariable);
>        }
>    }
> 
> In the kernel args, the iterationVariable is replaced by the stream source array so each GPU workitem gets its own unique array element to work on.
> 
> Since the HSA runtime does not have actual method/function call support yet, everything will have to get inlined into this method for the time being. In this naive prototype, I "train" this method 500 times through the normal CPU execution to get some profile, then divert to HSAIL.
> 
> With my junit for this work my actual types are:
> 
> predicate class: com.oracle.graal.compiler.hsail.test.lambda.MultiTest$$Lambda$1/1606304070
> consumer class : com.oracle.graal.compiler.hsail.test.lambda.MultiTest$$Lambda$2/1525409936
> 
> The problem I have met is that the compilation dependency checks fail on "abstract_with_unique_concrete_subtype" because there is more than 1 Predicate implementor loaded in the system, because Graal itself uses some Stream API, for example.
> 
> Is there a legitimate way to bypass this dependency check when compiling for HSAIL, where everything is funnelled through an offload pipeline under our control? Or is there a graceful solution to narrow the types going into the method? I am compiling this method specifically for HSAIL and it is sort of not really exposed to all the other types in the CPU side system.

The problem is that the compilation of the kernel can not (currently) know that since it does not have the context of the caller.

Based on the profile resulting from your training, I assume Graal will do guarded inlining for the Predicate and Consumer types you trained on. The “else” branch should result in a deopt and hence no need to worry about doing a call. Sounds like that is not happening?

-Doug