hsail gate commands -- webrev

Doug Simon doug.simon at oracle.com
Wed Jan 22 11:41:16 PST 2014


On Jan 22, 2014, at 8:37 PM, Deneau, Tom <tom.deneau at amd.com> wrote:

> Doug --
> 
> except that even the non-junit path (eg, Sumatra) does have dependencies on the okra classes.

When you say “Sumatra client”, what exactly do you mean?

> But maybe it doesn't need the huge resources to be in graal.jar, that would mean
> the non-junit Sumatra clients would have to set up the PATH/LD_LIBRARY_PATH just like they always did,
> they couldn't rely on the new "native library being loaded into the temporary directory" thing.

Yep, that will have to be a requirement.

> This would just be to reduce the size of graal.jar, if anybody cares.

Yes - we really don’t want to increase graal.jar by 46M! ;-)

-Doug

>> -----Original Message-----
>> From: Doug Simon [mailto:doug.simon at oracle.com]
>> Sent: Wednesday, January 22, 2014 1:26 PM
>> To: Deneau, Tom
>> Cc: graal-dev at openjdk.java.net
>> Subject: Re: hsail gate commands -- webrev
>> 
>> On Jan 22, 2014, at 8:15 PM, Deneau, Tom <tom.deneau at amd.com> wrote:
>> 
>>> Doug --
>>> 
>>> On a related topic, I'm assuming we do want these binary resources
>>> copied into the graal.jar file which is what currently happens.
>> 
>> Move the OKRA dependency from com.oracle.graal.asm.hsail to
>> com.oracle.graal.compiler.hsail.test.infra so it won't be included in
>> graal.jar
>> 
>> -Doug
>> 
>>>> -----Original Message-----
>>>> From: Deneau, Tom
>>>> Sent: Wednesday, January 22, 2014 11:04 AM
>>>> To: 'Doug Simon'
>>>> Cc: Tom Rodriguez; graal-dev at openjdk.java.net
>>>> Subject: RE: hsail gate commands -- webrev
>>>> 
>>>> Doug --
>>>> 
>>>> This okraLibExists force load of the library is only really useful on
>>>> the non-junit path, for example, when Sumatra is the client.
>>>> 
>>>> I can make the changes you recommend.
>>>> 
>>>> -- Tom
>>>> 
>>>>> -----Original Message-----
>>>>> From: Doug Simon [mailto:doug.simon at oracle.com]
>>>>> Sent: Wednesday, January 22, 2014 5:58 AM
>>>>> To: Deneau, Tom
>>>>> Cc: Tom Rodriguez; graal-dev at openjdk.java.net
>>>>> Subject: Re: hsail gate commands -- webrev
>>>>> 
>>>>> This all seems to work - nice job. Just a few requests/comments
>>>>> before I integrate.
>>>>> 
>>>>> HSAILCompilationResult.java:
>>>>> 
>>>>> 60     // this test of okraLib existence is to allow the loading of
>>>>> the
>>>>> 61     // native library from the jar file if it is not already on
>>>> the
>>>>> path
>>>>> 62     private static boolean okraLibExists =
>>>>> OkraUtil.okraLibExists();
>>>>> 
>>>>> The above assignment produces a "value of field is not used" warning
>>>>> in Eclipse. It seems that all you want here is the side-effect of
>>>>> the call to OkraUtil.okraLibExists(). If that's the case, just put
>>>>> the call in a static initializer block and delete the field:
>>>>> 
>>>>> static {
>>>>>   OkraUtil.okraLibExists();
>>>>> }
>>>>> 
>>>>> However, I tried just commenting out the line altogether and the
>>>>> unit tests seemed to still run fine. Which begs the question, do you
>>>>> really need this here?
>>>>> 
>>>>> Can you also please update (and re-upload) okra-with-sim.jar to
>>>>> include the Java sources (just like okra-1.2.jar had). This helps
>>>>> with debugging the code in Eclipse.
>>>>> 
>>>>> -Doug
>>>>> 
>>>>> On Jan 21, 2014, at 6:07 PM, Deneau, Tom <tom.deneau at amd.com> wrote:
>>>>> 
>>>>>> All --
>>>>>> 
>>>>>> I have uploaded a webrev to allow use of the hsail simulator
>>>>>> without
>>>>> setting up any PATH or LD_LIBRARY_PATH variables to make it easier
>>>>> to run the hsail junit tests as part of the graal gate:
>>>>>> 
>>>>>> http://cr.openjdk.java.net/~tdeneau/graal-webrevs/webrev-lazy-nativ
>>>>>> e
>>>>>> -h
>>>>>> sail-library-open/webrev/
>>>>>> 
>>>>>> * The main change was in gpu_hsail.cpp to lazily load the native
>>>>> library,
>>>>>>   (waiting until it is really needed).  It always tries the
>>>>>> original
>>>>> LD_LIBRARY_PATH
>>>>>>   as a first try, and only if that doesn't work, it will try
>>>>>>   the environment variable _OKRA_SIM_LIB_PATH_ (which will have
>>>>>> been
>>>>> set up by the
>>>>>>   java side which will have copied the native library and hsailasm
>>>>> to a temporary
>>>>>>   directory if necessary)
>>>>>> 
>>>>>> * HSAILCompilationResult, added a call the the JNI side to get it
>>>>>> to
>>>>> load the native library
>>>>>>   from the jar file if it needs to.
>>>>>> 
>>>>>> * mx/projects changed to use the newly built okra-with-sim.jar
>>>>>> which
>>>>> has been uploaded to
>>>>>>   my cr.openjdk.java.net directory (the old okra.jar came from
>>>>>> there
>>>>> as well).
>>>>>>   This jar file contains the prebuilt binaries but can also be
>>>>>> built
>>>>> from sources
>>>>>>   following the instructions at
>>>>>> 
>>>>>> https://github.com/HSAFoundation/Okra-Interface-to-HSAIL-Simulator
>>>>>> 
>>>>>> To test:
>>>>>> * make sure not only that the okra/dist/bin directory
>>>>>>   is removed from PATH and LD_LIBRARY_PATH but also that it is not
>>>>> one of the directories
>>>>>>   listed under "ldconfig -p"
>>>>>> 
>>>>>> 
>>>>>> The changes to the okra.jar file and the native library are not
>>>>>> part of this webrev, but if interested, these changes can be viewed
>>>>>> as a pull request on the github directory
>>>>>> https://github.com/HSAFoundation/Okra-Interface-to-HSAIL-Simulator/
>>>>>> p
>>>>>> ul
>>>>>> l/11
>>>>>> 
>>>>>> * Again, the native library loading as performed by the
>>>>>> OkraContext
>>>>> class
>>>>>>   first tries the original PATH and LD_LIBRARY_PATH strategy
>>>>>> before
>>>>> reverting
>>>>>>   to using a temporary directory.  It looks in the jar file that
>>>>> OkraContext.class
>>>>>>   was loaded from and copies anything in resources/okra to a
>>>>> temporary directory.
>>>>>>   Then it tries to load the native library from there.
>>>>>> 
>>>>>> * the native library itself now contains an on_load function
>>>>>>   with attribute((constructor)) which gets executed as the .so
>>>>>> file
>>>>> gets loaded.
>>>>>>   It does the following:
>>>>>>      * finds out where it was loaded from (using dladdr)
>>>>>>      * appends that directory to PATH and LD_LIBRARY_PATH (this
>>>>> allows
>>>>>>        a later invoke of hsailasm to work)
>>>>>>      * sets an environment variable _OKRA_SIM_LIB_PATH_.  This env
>>>>> var
>>>>>>        is used later by the JVM when it wants to load the native
>>>>> library
>>>>>>        and discover its C-based entry points.
>>>>>> 
>>>>>> -- Tom
>>>>>> 
>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com]
>>>>>>> Sent: Wednesday, January 15, 2014 4:15 PM
>>>>>>> To: Douglas Simon
>>>>>>> Cc: Deneau, Tom; graal-dev at openjdk.java.net
>>>>>>> Subject: Re: hsail gate commands
>>>>>>> 
>>>>>>> dladdr can also be used to figure it out directly.
>>>>>>> 
>>>>>>> tom
>>>>>>> 
>>>>>>> On Jan 15, 2014, at 2:07 PM, Doug Simon <doug.simon at oracle.com>
>>>>> wrote:
>>>>>>> 
>>>>>>>> 
>>>>>>>> On Jan 15, 2014, at 10:46 PM, Deneau, Tom <tom.deneau at amd.com>
>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Doug --
>>>>>>>>> 
>>>>>>>>> how does the JNI_OnLoad know what path it was loaded from?
>>>>>>>>> or would the java side have to pass this information down?
>>>>>>>> 
>>>>>>>> The Java side has to pass this down. One way to do it would be to
>>>>>>> define a static String field in some class in the Okra Java
>>>>>>> library and assign it the path before calling System.load().
>>>>>>> Inside JNI_OnLoad, the JNI interface can be used to find the class
>>>>>>> and read
>>>>> the field.
>>>>>>>> 
>>>>>>>> -Doug
>>>>>>>> 
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Doug Simon [mailto:doug.simon at oracle.com]
>>>>>>>>>> Sent: Wednesday, January 15, 2014 3:11 PM
>>>>>>>>>> To: Deneau, Tom
>>>>>>>>>> Cc: graal-dev at openjdk.java.net
>>>>>>>>>> Subject: Re: hsail gate commands
>>>>>>>>>> 
>>>>>>>>>> Hi Tom,
>>>>>>>>>> 
>>>>>>>>>> A quick glance through the HSAIL C++ layer seems to indicate
>>>>>>>>>> that it should be able to lazily initialize the HSAIL library
>>>>>>>>>> linkage
>>>>>>> (currently
>>>>>>>>>> done in gnu::Hsail::probe_linkage()). This means it should be
>>>>>>> deferrable
>>>>>>>>>> until after the Java part of the Okra library has had a chance
>>>>>>>>>> to extract the native library file (and hsailasm executable)
>>>>>>>>>> into the
>>>>>>> file
>>>>>>>>>> system. Then you would call System.load() to load the library.
>>>>>>> There's
>>>>>>>>>> still the problem of how to communicate the absolute path of
>>>>>>>>>> the
>>>>>>> native
>>>>>>>>>> library to the os::dll_load call. There may be a more elegant
>>>>>>> solution,
>>>>>>>>>> but I'd suggest using the JNI_OnLoad[1] mechanism. Inside the
>>>>>>> JNI_OnLoad
>>>>>>>>>> function in the Okra native library, you can set an environment
>>>>>>> variable
>>>>>>>>>> (e.g., OKRA_DLL_PATH) which gnu::Hsail::probe_linkage can then
>>>>> use.
>>>>>>> Note
>>>>>>>>>> that the environment variable has to be set this way as there's
>>>>>>>>>> no
>>>>>>> way
>>>>>>>>>> to set an environment variable from Java.
>>>>>>>>>> 
>>>>>>>>>> By the time you finish all this hackery, you may start thinking
>>>>>>>>>> that simply porting the HSAIL simulator/toolchain to Java might
>>>>>>>>>> be easier
>>>>>>> ;-)
>>>>>>>>>> 
>>>>>>>>>> [1]
>>>>>>>>>> 
>>>>>>> 
>> http://docs.oracle.com/javase/1.5.0/docs/guide/jni/spec/invocation.
>>>>>>> ht
>>>>>>> ml#
>>>>>>>>>> JNI_OnLoad
>>>>>>>>>> 
>>>>>>>>>> On Jan 15, 2014, at 9:05 PM, Deneau, Tom <tom.deneau at amd.com>
>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Doug --
>>>>>>>>>>> 
>>>>>>>>>>> One complication I saw here.
>>>>>>>>>>> The native library file is used both from the java side (using
>>>>>>>>>>> loadLibrary) and from the hotspot side (using os::dll_load
>>>>>>>>>>> followed
>>>>>>> by
>>>>>>>>>> looking up the specific functions it needs).
>>>>>>>>>>> And the hotspot attempt to load happens first (from
>>>> gpu::init()).
>>>>>>>>>>> 
>>>>>>>>>>> So anything the java side would have done with resources in
>>>>>>>>>>> the
>>>>>>> .jar
>>>>>>>>>>> file and temp directories wouldn't have been done yet.
>>>>>>>>>>> 
>>>>>>>>>>> -- Tom
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Doug Simon [mailto:doug.simon at oracle.com]
>>>>>>>>>>>> Sent: Tuesday, January 14, 2014 3:27 AM
>>>>>>>>>>>> To: Deneau, Tom
>>>>>>>>>>>> Cc: graal-dev at openjdk.java.net
>>>>>>>>>>>> Subject: Re: hsail gate commands
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Jan 13, 2014, at 8:52 PM, Deneau, Tom <tom.deneau at amd.com>
>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Doug --
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Using the techniques in
>>>>>>>>>>>>> http://frommyplayground.com/how-to-load-native-jni-library-f
>>>>>>>>>>>>> r
>>>>>>>>>>>>> om
>>>>>>>>>>>>> -
>>>>>>> jar/
>>>>>>>>>>>>> that you sent, would it be acceptable to leave hsailasm as a
>>>>>>>>>>>>> separate
>>>>>>>>>>>> executable which gets unjarred into the system temporary
>>>>>>>>>>>> directory and then executed from there using an absolute
>>>>> pathname?
>>>>>>>>>>>> 
>>>>>>>>>>>> Sounds feasible and reasonable to me.
>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> -- Tom
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>> From: Doug Simon [mailto:doug.simon at oracle.com]
>>>>>>>>>>>>>> Sent: Sunday, January 12, 2014 2:29 PM
>>>>>>>>>>>>>> To: Deneau, Tom
>>>>>>>>>>>>>> Subject: Re: hsail gate commands
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Jan 9, 2014, at 9:50 PM, Deneau, Tom
>>>>>>>>>>>>>> <tom.deneau at amd.com>
>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Doug --
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> We'll take a look at your suggestion.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Great.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> BTW, you guys may want to bring
>>>>>>>>>>>>>> 
>>>>>>> https://wiki.openjdk.java.net/display/Sumatra/The+HSAIL+Simulator
>>>>>>>>>>>>>> more up to date at some point. At least you can remove the
>>>>>>> "(webrev
>>>>>>>>>>>>>> under review)" qualifications.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> -Doug
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>> From: Doug Simon [mailto:doug.simon at oracle.com]
>>>>>>>>>>>>>>>> Sent: Thursday, January 09, 2014 1:38 PM
>>>>>>>>>>>>>>>> To: Deneau, Tom
>>>>>>>>>>>>>>>> Cc: graal-dev at openjdk.java.net
>>>>>>>>>>>>>>>> Subject: Re: hsail gate commands
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Jan 9, 2014, at 6:51 PM, Tom Rodriguez
>>>>>>>>>>>>>>>> <tom.rodriguez at oracle.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> It would still be great if there would be some way to
>>>>>>>>>>>>>>>>>>>> incorporate
>>>>>>>>>>>>>>>> the hsail simulator into the gate...
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> A good start would be if you could provide us with a
>>>>>>>>>>>>>>>>>>> patch
>>>>>>> for
>>>>>>>>>>>>>>>>>>> `mx',
>>>>>>>>>>>>>>>> that adds a command which sets up the HSAIL simulator
>>>>>>> properly.
>>>>>>>>>>>>>>>> Currently our gate is running on Linux, but this might
>>>>>>>>>>>>>>>> change
>>>>>>> in
>>>>>>>>>>>>>>>> the future, so keep in mind that this should potentially
>>>>>>>>>>>>>>>> work
>>>>>>> on
>>>>>>>>>>>>>>>> all platforms (Linux, MacOSX, Windows).
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Our gate server is basically executing `mx gate' to
>>>>>>> validate
>>>>>>>>>>>>>>>> changes. That includes building, bootstrap tests,
>>>>>>>>>>>>>>>> unittest,
>>>>>>> etc.
>>>>>>>>>>>>>>>> If that command was successful on our gate server, the
>>>>>>>>>>>>>>>> changes are accepted and pushed to the repository.
>>>>>>>>>>>>>>>> Having the `mx
>>>>>>> gate'
>>>>>>>>>>>>>>>> command, one can reproduce the gate process on his/her
>>>>>>>>>>>>>>>> local
>>>>>>>>>>>> machine.
>>>>>>>>>>>>>>>> Therefore it would be important that one can easily and
>>>>>>> reliable
>>>>>>>>>>>>>>>> set up the HSAIL environment if it is part of the gate
>>>>>>> process.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Given the dependencies for building the simulator[1]
>>>>>>>>>>>>>>>>>> and the fact it
>>>>>>>>>>>>>>>> only currently runs on linux, I don't think it will be
>>>>>>>>>>>>>>>> that
>>>>>>> easy
>>>>>>>>>>>>>>>> to come up with an mx command.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> What precompiling an okra distribution for linux that mx
>>>>>>>>>>>>>>>>> can
>>>>>>>>>>>>>> download?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> If Okra used a self contained JNI library, that might
>>>>>>>>>>>>>>>> just
>>>>>>> work.
>>>>>>>>>>>>>>>> However, the way it is deployed now involves having the
>>>>>>> hsailasm
>>>>>>>>>>>>>>>> executable on your PATH. Also, LD_LIBRARY_PATH has to be
>>>>>>>>>>>>>>>> setup
>>>>>>> to
>>>>>>>>>>>>>>>> find the JNI library itself.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> @AMD guys: How hard would it be to make the Okra JNI be
>>>>>>>>>>>>>>>> self contained library and include the hsailasm
>>>>>>>>>>>>>>>> functionality? If that's possible, you could bundle the
>>>>>>>>>>>>>>>> JNI library inside the
>>>>>>> Okra
>>>>>>>>>>>>>>>> jar using a technique like
>>>>>>>>>>>>>>>> http://frommyplayground.com/how-to-load-native-jni-librar
>>>>>>>>>>>>>>>> y
>>>>>>>>>>>>>>>> -
>>>>>>> from-j
>>>>>>>>>>>>>>>> ar
>>>>>>>>>>>>>>>> /
>>>>>>>>>>>>>> to avoid having to set up PATH or LD_LIBRARY_PATH.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> -Doug
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>>> https://github.com/HSAFoundation/Okra-Interface-to-HSAI
>>>>>>>>>>>>>>>>>> L
>>>>>>>>>>>>>>>>>> -
>>>>>>> Simula
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> r#
>>>>>>>>>>>>>>>>>> ok
>>>>>>>>>>>>>>>>>> ra-interface-to-hsail-simulator
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>>>>>> From: graal-dev-bounces at openjdk.java.net
>>>>>>>>>>>>>>>>>>>>> [mailto:graal-
>>>>>>> dev-
>>>>>>>>>>>>>>>>>>>>> bounces at openjdk.java.net] On Behalf Of Deneau, Tom
>>>>>>>>>>>>>>>>>>>>> Sent: Monday, December 16, 2013 11:24 AM
>>>>>>>>>>>>>>>>>>>>> To: Doug Simon
>>>>>>>>>>>>>>>>>>>>> Cc: graal-dev at openjdk.java.net
>>>>>>>>>>>>>>>>>>>>> Subject: RE: hsail gate commands
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> OK, I see why there is no error when running mx --vm
>>>>>>> server
>>>>>>>>>>>>>>>>>>>>> unittest hsail
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> At some point (I don't recall why, maybe at Oracle's
>>>>>>>>>>>>>>>>>>>>> request??), we put in some code in KernelTester that
>>>>>>>>>>>>>>>>>>>>> if
>>>>>>> it
>>>>>>>>>>>>>>>>>>>>> could not find the okra simulator files would just
>>>>>>> silently
>>>>>>>>>>>>>>>>>>>>> not run the tests (which I guess counts as a pass).
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> No the hsail simulator is not a java app at all.
>>>>>>>>>>>>>>>>>>>>> The page at
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>> https://wiki.openjdk.java.net/display/Sumatra/The+HSAIL+Simu
>>>>>>>>>>>>>>>>>>>>> la to r should describe how to build it and what
>>>>>>> environment
>>>>>>>>>>>>>>>>>>>>> variables to set up to use it...
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> -- Tom
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>>>>>>> From: Doug Simon [mailto:doug.simon at oracle.com]
>>>>>>>>>>>>>>>>>>>>>> Sent: Monday, December 16, 2013 11:02 AM
>>>>>>>>>>>>>>>>>>>>>> To: Deneau, Tom
>>>>>>>>>>>>>>>>>>>>>> Cc: graal-dev at openjdk.java.net
>>>>>>>>>>>>>>>>>>>>>> Subject: Re: hsail gate commands
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> On Dec 16, 2013, at 5:48 PM, Deneau, Tom
>>>>>>>>>>>>>>>>>>>>>> <tom.deneau at amd.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> Doug --
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> I see.
>>>>>>>>>>>>>>>>>>>>>>> I don't understand why the tests would run without
>>>>>>> error
>>>>>>>>>>>>>>>>>>>>>>> if the simulator and associated assembler is
>>>>>>>>>>>>>>>>>>>>>>> missing
>>>>>>>>>> but...
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> What error are you seeing?
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> Is there a way we can get the HSAIL simulator into
>>>>>>>>>>>>>>>>>>>>>>> the gate
>>>>>>>>>>>>>>>>>>>>>> infrastructure?
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> Is it a pure Java app yet? That would certainly
>>>>>>>>>>>>>>>>>>>>>> make it
>>>>>>>>>>>>>> trivial.
>>>>>>>>>>>>>>>>>>>>>> In any case, I'll defer to Bernhard or Gilles to
>>>>>>>>>>>>>>>>>>>>>> answer this since they are the maintainers of this
>>>>>>> infrastructure.
>>>>>>>>>>>>>>>>>>>>>> Can you please send instructions on how to
>>>>>>>>>>>>>>>>>>>>>> install/use/configure the
>>>>>>>>>>>>>>>> simulator.
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> -Doug
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>>>>>>>>> From: Doug Simon [mailto:doug.simon at oracle.com]
>>>>>>>>>>>>>>>>>>>>>>>> Sent: Monday, December 16, 2013 10:36 AM
>>>>>>>>>>>>>>>>>>>>>>>> To: Deneau, Tom
>>>>>>>>>>>>>>>>>>>>>>>> Cc: graal-dev at openjdk.java.net
>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: hsail gate commands
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> On Dec 16, 2013, at 5:21 PM, Deneau, Tom
>>>>>>>>>>>>>>>>>>>>>>>> <tom.deneau at amd.com>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Doug --
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> I noticed in syncing with the trunk as of last
>>>>>>>>>>>>>>>>>>>>>>>>> Friday that all of our
>>>>>>>>>>>>>>>>>>>>>>>> HSAIL test cases broke.  The cause was some
>>>>>>>>>>>>>>>>>>>>>>>> imperfect code in our HSAILAssembler for compare
>>>>>>>>>>>>>>>>>>>>>>>> instructions
>>>>>>> which
>>>>>>>>>>>>>>>>>>>>>>>> when presented with an unordered compare could
>>>>>>> generate
>>>>>>>>>>>>>>>>>>>>>>>> code that would not assemble, and was easy to
>> fix.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> But I was wondering how this made it past the
>>>> gate.
>>>>>>>>>>>>>>>>>>>>>>>>> Can you describe what gate commands are used
>>>>>>> regarding
>>>>>>>>>>>>>> hsail?
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> We simply run 'mx gate' which will include
>>>>>>>>>>>>>>>>>>>>>>>> running all the HSAIL unit tests.
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> On my Mac with the latest bits:
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> $ mx --vm server unittest hsail executing junit
>>>>>>>>>>>>>>>>>>>>>>>> tests
>>>>>>>>>>>> now...
>>>>>>>>>>>>>>>>>>>>>>>> (107 test classes) JUnit version 4.8
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>> 
>>>>> 
>>>> 
>> ........................................................................
>>>>>>>>>>>>>>>>>>>>>>>> ...........I................I......
>>>>>>>>>>>>>>>>>>>>>>>> Time: 5.525
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> OK (105 tests)
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> Keep in mind I (and the gate infrastructure)
>>>>>>>>>>>>>>>>>>>>>>>> don't
>>>>>>> have
>>>>>>>>>>>>>>>>>>>>>>>> the HSAIL simulator.
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> -Doug
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>> 
>>> 
>> 
> 
> 



More information about the graal-dev mailing list