Substitution/Replacements problem

[Eric Caspole]

Hi everybody,
We have a lot of lambda based tests that are not in the public repo yet, 
waiting for JDK 8 to come to Graal. In these tests, I found a problem 
with the way replacements are being done now.

See this method:

graal/com.oracle.graal.hotspot/src/com/oracle/graal/hotspot/HotSpotReplacementsImpl.java


107     @Override
108     public StructuredGraph getMethodSubstitution(ResolvedJavaMethod 
original) {
109         for (GraphProducer gp : graphProducers) {
110             StructuredGraph graph = gp.getGraphFor(original);
111             if (graph != null) {
112                 return graph;
113             }
114         }
115         return super.getMethodSubstitution(original);
116     }


Here it loops over the backends until it gets a hit. In our tests, I 
found that while we are compiling an HSAIL kernel that is actually a 
Stream API lambda, when it goes into getIntrinsicGraph(), it will go 
into getMethodSubstitution() and look for substitutions in the PTX 
backend, see the "lambda$" method we are compiling and try to produce a 
PTX kernel of the thing we are in the middle of compiling for HSAIL, 
which was a shock :)

Up til now, we have been using the replacements/inline mechanism for 
example AtomicInteger that end up as fence/load/fence type ops, and 
other uses, that get inlined into the kernel body and that is working 
well so far.

I have a suitable PTX card in my box so I might be the only one in the 
group that might see this problem. The existing HSAIL KernelTester tests 
in the public repo do not get this problem since the harness sends an 
ordinary method to get HSAIL-compiled and they are not called "lambda$..."

I think I see that the strategy for offloading for PTX so far is doing a 
"replacement" of a CPU method with a GPU kernel. But we also want to 
have some replacements/inlining inside the kernel.

What is the best way to fix this problem?
Thanks,
Eric