compiling code that has never been interpreted

[Doug Simon]

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
>> 
> 
> 
>