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