compiling code that has never been interpreted

Deneau, Tom tom.deneau at amd.com
Tue Sep 3 13:45:26 PDT 2013


Doug --

False alarm, the nbody test related failures noted below were initialization problems in the junit tests.
But getEagerDefault was necessary to resolve several other test failures.

-- Tom


-----Original Message-----
From: Deneau, Tom 
Sent: Tuesday, September 03, 2013 11:47 AM
To: 'Doug Simon'
Cc: graal-dev at openjdk.java.net
Subject: RE: compiling code that has never been interpreted

Doug --

I spoke too soon in saying that GraphBuilderConfiguration.getEagerDefault() solved our problems.
There are still a few junit tests that fail if we compile never-previously-executed code even though we are using getEagerDefault.  The failures are all variations of the nbody test.
I can see the codegen differing very slightly.  I will try to send examples.

-- Tom


-----Original Message-----
From: Doug Simon [mailto:doug.simon at oracle.com]
Sent: Tuesday, September 03, 2013 10:29 AM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net
Subject: Re: compiling code that has never been interpreted

On Sep 3, 2013, at 5:21 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:

> Doug --
> 
> Thanks, yet this works.
> What is the reason that someone would want eagerResolving turned off?

Two reasons (that I can think of):

1. Prevent non-executed code paths causing extra class loading during compilation.
2. Allows unresolved calls to be treated as deopt points which can improve type analysis and a number of other compiler analyses.

-Doug

> -----Original Message-----
> From: Doug Simon [mailto:doug.simon at oracle.com]
> Sent: Tuesday, September 03, 2013 10:00 AM
> To: Deneau, Tom
> Cc: graal-dev at openjdk.java.net
> Subject: Re: compiling code that has never been interpreted
> 
> Using GraphBuilderConfiguration.getEagerDefault() in HSAILCompilationResult.getHSAILCompilationResult() should work.
> 
> On Sep 3, 2013, at 2:52 PM, "Deneau, Tom" <tom.deneau at amd.com> wrote:
> 
>> For the HSAIL-based junit tests, we have the following general structure:
>> 
>> 1.       run a method in normal java mode
>> 
>> 2.       compile same method into HSAIL and dispatch
>> 
>> 3.       compare results
>> 
>> If the first two steps above are reversed, such that we force graal to compile a method which may have never been executed in java, there are some cases where the graal-generated HSAIL code is clearly incorrect, seemingly missing whole methods which should be inlined, etc.  (We are compiling with the flag -G:+InlineEverything).  We are running --vm server.
>> 
>> Is there a flag that should be used to handle such a case where we are trying to compile something that may have never been interpreted?  Or is this not supported?
>> 
>> I can try to get igv graphs if needed.
>> 
>> -- Tom
>> 
> 
> 
> 





More information about the graal-dev mailing list