scoped overriding of graal options

[Doug Simon]

On Nov 8, 2013, at 11:44 PM, Deneau, Tom <tom.deneau at amd.com> wrote:

> Doug --
> 
> OK, this still looks very useful.
> One small complaint, I did a println of the overridden option while debugging, and it just showed the original value from the command line.
> 
> Maybe toString could show both the original value and the overridden value (if different)

I modified toString() to show the current value and added a getValues() method to be able to access the overriding chain.

-Doug

> -----Original Message-----
> From: Doug Simon [mailto:doug.simon at oracle.com] 
> Sent: Thursday, November 07, 2013 4:05 PM
> To: Deneau, Tom
> Cc: graal-dev at openjdk.java.net
> Subject: Re: webrev for hsail backend merging with new providers infrastructure
> 
> 
> On Nov 7, 2013, at 10:54 PM, Deneau, Tom <tom.deneau at amd.com> wrote:
> 
>> Doug --
>> 
>> Sometimes we want to run a test with several different max heap sizes because it forces different types of Compressed Oops encoding, etc.  Can that type of change be handled by this scoped overriding of options? (I assume not).
> 
> Unfortunately not. The scoped overriding mechanism is only supported for Graal options, not HotSpot options.
> 
> -Doug
> 
>> -----Original Message-----
>> From: Doug Simon [mailto:doug.simon at oracle.com] 
>> Sent: Tuesday, November 05, 2013 8:06 AM
>> To: Deneau, Tom
>> Cc: graal-dev at openjdk.java.net
>> Subject: Re: webrev for hsail backend merging with new providers infrastructure
>> 
>> 
>> On Nov 4, 2013, at 6:19 PM, Doug Simon <doug.simon at oracle.com> wrote:
>> 
>>> 
>>> On Nov 4, 2013, at 5:27 PM, Deneau, Tom <tom.deneau at amd.com> wrote:
>>> 
>>>> Hi Doug --
>>>> 
>>>> Some of our java 8 based unit tests (which use lambdas) use these two libraries currently, but you're right we don't use them in the java 7 based tests yet.  If you want to remove them from the public mx/projects, go ahead.
>>>> 
>>>> This points to a hole in our testing strategy which we've always been aware of.  We have written a number of java 8 style unit tests that we test locally here but that don't get exercised in the public repository.  We could of course add similar java 7 based unit tests and push them to public but we haven't done that work, and if graal is going to support 8 soon, there wouldn't be a need for that conversion work.
>>> 
>>> Yes, I suggest to keep just running these tests locally until Graal has transitioned to 8.
>>> 
>>>> On a related note, I think Vasanth mentioned that we run our unit tests locally here with the flags -G:+InlineEverything  -G:-RemoveNeverExecutedCode.   We need InlineEverything because we don't support HSAIL function calls yet.  Several test cases have a line like
>>>>    assumeTrue(aggressiveInliningEnabled());
>>>> 
>>>> and of course these just get skipped if -G:+InlineEverything is not set.  Is it possible to get the hsail tests that get run at Oracle to use these two flags?
>>> 
>>> We don't currently have infrastructure for running tests in a different VM instances based on required command line option settings. What we ideally want (in this case at least) is for options such as InlineEverything and RemoveNeverExecutedCode to be overridable in a scoped manner (e.g., for individual compilations). Until we have support for this however, we'll have to rely on your testing setup to run these tests.
>> 
>> There is now support for scoped overriding of options[1]. For example, in StaticNBodyCallTest:
>> 
>>   @Test
>>   @Override
>>   public void test() throws Exception {
>>       Field f = GraalOptions.class.getDeclaredField("RemoveNeverExecutedCode");
>>       f.setAccessible(true);
>>       OptionValue<?> removeNeverExecutedCode = (OptionValue<?>) f.get(null);
>>       try (OverrideScope s = OptionValue.override(GraalOptions.InlineEverything, true, removeNeverExecutedCode, false)) {
>>           assumeTrue(aggressiveInliningEnabled() || canHandleHSAILMethodCalls());
>>           testGeneratedHsail();
>>       }
>>   }
>> 
>> 
>> [1] http://hg.openjdk.java.net/graal/graal/rev/38bf986ce231
>> 
>> -Doug
>> 
>>>> -----Original Message-----
>>>> From: Doug Simon [mailto:doug.simon at oracle.com] 
>>>> Sent: Monday, November 04, 2013 9:30 AM
>>>> To: Deneau, Tom
>>>> Cc: graal-dev at openjdk.java.net
>>>> Subject: Re: webrev for hsail backend merging with new providers infrastructure
>>>> 
>>>> Actually, one quick question: Do we really need the VECMATH and APACHELANG libraries declared in mx/projects[1]? None of the projects seem to use them.
>>>> 
>>>> -Doug
>>>> 
>>>> [1] http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/mx/projects.udiff.html
>>>> 
>>>> On Nov 1, 2013, at 11:54 PM, Deneau, Tom <tom.deneau at amd.com> wrote:
>>>> 
>>>>> All --
>>>>> 
>>>>> I have posted a small webrev to
>>>>> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-infrastructure-merge/webrev/
>>>>> 
>>>>> This is the result of our merge with the recent providers infrastructure.  Could you please look this over?
>>>>> 
>>>>> Here is a brief summary:
>>>>> 
>>>>> 
>>>>> HSAILHotSpotForeignCallsProvider.java
>>>>> -------------------------------------
>>>>> . As noted in the comments,   we don't really support foreign calls yet,  yet we do get asked to handle ForeignCall nodes, and we want to generate dummy code for them.  We just support them all and lazily create dummy linkages here.  When we finally support foreign calls we will explicitly register the ones we want to support. 
>>>>> 
>>>>> HSAILHotSpotLIRGenerator.java, HSAILLIRGenerator.java, HSAILControlFlow.java
>>>>> ----------------------------------------------------------------------------
>>>>> . This again is part of the dummy Foreign Call support.   Some less extensive ForeignCall support used to be in HSAILLIRGenerator.
>>>>> 
>>>>> HSAILHotSpotReplacementsImpl.java
>>>>> ---------------------------------
>>>>> . This is another one of the providers in the new runtime infrastructure.  For both macro substitutions and method substitutions, we just delegate to the host substitution list.  This is a quick solution which allows things like Math.sqrt, and some of the Unsafe methods to work for HSAIL, similar to the way these substitutions worked before the providers change.  Eventually, we will explicitly list which substitutions we will support.
>>>>> 
>>>>> HSAIL.java
>>>>> ----------
>>>>> . Not really part of the webrev infrastructure merge but since we're planning to limit the number of registers actually used by the graal compiler, it seemed appropriate to push this out.
>>>>> 
>>>>> Tests
>>>>> -----
>>>>> . With the ForeignCall support above, some test cases that were marked as failing are now passing.
>>>>> 
>>>>> KernelTester.java
>>>>> -----------------
>>>>> . Not really part of the webrev infrastructure merge but added a property to allow running the gpu code either first or second vs. the java code in our test cases.
>>>>> 
>>>>> 
>>>>> -- Tom Deneau
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
> 
> 
>