From rellermeyer at us.ibm.com  Fri May  8 20:01:41 2015
From: rellermeyer at us.ibm.com (Jan S Rellermeyer)
Date: Fri, 8 May 2015 15:01:41 -0500
Subject: hotspot: problem with bitwise rotation on PowerLE
Message-ID: <OFF86722F2.508E098C-ON86257E3F.006CCF46-86257E3F.006E0494@us.ibm.com>



I am helping people in IBM who have encountered a hotspot bug that surfaces
when using bitwise rotations (such as through Integer.rotateRight). I have
attached a small test program that illustrates the problem. When running
this on Power LE (I don't think that anybody tried on BE, though) the
results of the hash function are incorrect.

The bug goes away when disabling inlining. After digging through the
generated code I found out that it contained some suspicious fnmadd
instructions where you would rather expect some kind of left rotate. I
could track down that the bug was caused by the immediate value for the
right shift constant of what should be a rlwinm node to be negative and
thereby bleeding into the opcode (which unfortunately still created a valid
Power instruction, namely the fnmadd). Running with a fastdebug build
causes an assertion to fail.

The attached patch does fix the problem and so does an alternative patch
that replaces the URshift with a UShift but I am not entirely sure if this
really fixes the root cause or rather just prevents the rotlI instruction
from being matched by the ReduceInst.

--Jan.


Dr. Jan S. Rellermeyer
IBM Research
RSM - Austin Research Lab
rellermeyer_at_us.ibm.com
The University of Texas at Austin
Adjunct Assistant Professor
jrellerm_at_cs.utexas.edu

(See attached file: hash.java)(See attached file: rotl.patch)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20150508/3811e86d/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: hash.java
Type: application/octet-stream
Size: 4739 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20150508/3811e86d/hash-0001.java>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rotl.patch
Type: application/octet-stream
Size: 890 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20150508/3811e86d/rotl-0001.patch>

From asmundak at google.com  Tue May 12 04:06:10 2015
From: asmundak at google.com (Alexander Smundak)
Date: Mon, 11 May 2015 21:06:10 -0700
Subject: hotspot: problem with bitwise rotation on PowerLE
In-Reply-To: <OFF86722F2.508E098C-ON86257E3F.006CCF46-86257E3F.006E0494@us.ibm.com>
References: <OFF86722F2.508E098C-ON86257E3F.006CCF46-86257E3F.006E0494@us.ibm.com>
Message-ID: <CAHQ51u4V=hzOv39oN7nPOwNfzBg6Sx_2_WMhgT3zPx+U=5Zo2g@mail.gmail.com>

Looking into this. Sorry for the late response, we were moved into a
different office over the weekend.

On Fri, May 8, 2015 at 1:01 PM, Jan S Rellermeyer
<rellermeyer at us.ibm.com> wrote:
> I am helping people in IBM who have encountered a hotspot bug that surfaces
> when using bitwise rotations (such as through Integer.rotateRight). I have
> attached a small test program that illustrates the problem. When running
> this on Power LE (I don't think that anybody tried on BE, though) the
> results of the hash function are incorrect.
>
> The bug goes away when disabling inlining. After digging through the
> generated code I found out that it contained some suspicious fnmadd
> instructions where you would rather expect some kind of left rotate. I could
> track down that the bug was caused by the immediate value for the right
> shift constant of what should be a rlwinm node to be negative and thereby
> bleeding into the opcode (which unfortunately still created a valid Power
> instruction, namely the fnmadd). Running with a fastdebug build causes an
> assertion to fail.
>
> The attached patch does fix the problem and so does an alternative patch
> that replaces the URshift with a UShift but I am not entirely sure if this
> really fixes the root cause or rather just prevents the rotlI instruction
> from being matched by the ReduceInst.
>
> --Jan.
>
>
> Dr. Jan S. Rellermeyer
> IBM Research
> RSM - Austin Research Lab
> rellermeyer_at_us.ibm.com
> The University of Texas at Austin
> Adjunct Assistant Professor
> jrellerm_at_cs.utexas.edu
>
> (See attached file: hash.java)(See attached file: rotl.patch)

From volker.simonis at gmail.com  Tue May 12 12:38:40 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 12 May 2015 14:38:40 +0200
Subject: hotspot: problem with bitwise rotation on PowerLE
In-Reply-To: <CAHQ51u4V=hzOv39oN7nPOwNfzBg6Sx_2_WMhgT3zPx+U=5Zo2g@mail.gmail.com>
References: <OFF86722F2.508E098C-ON86257E3F.006CCF46-86257E3F.006E0494@us.ibm.com>
	<CAHQ51u4V=hzOv39oN7nPOwNfzBg6Sx_2_WMhgT3zPx+U=5Zo2g@mail.gmail.com>
Message-ID: <CA+3eh10ObFX-_A0ajkFC5P5yefbcTCFRMs_O=u=3HfZaazozNA@mail.gmail.com>

Hi,

this problem is not LE-related. I could reproduce it on BE as well. I
also don't think that the fix proposed by Jan is completely right. I
think it only helps because it leads to another instruction being
matched. The problem is that the URshift has a negative input which
should not be. It should have been converted to it's positive
equivalent modulo 32 (as described in the  JLS 15.19 -
https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.19).

Strange enough, in our internal version, the error doesn't occur so I
should actually easy find the difference. Unfortunately, I didn't saw
it until now :(
I'll keep you posted once I found out more...

Regards,
Volker

On Tue, May 12, 2015 at 6:06 AM, Alexander Smundak <asmundak at google.com> wrote:
> Looking into this. Sorry for the late response, we were moved into a
> different office over the weekend.
>
> On Fri, May 8, 2015 at 1:01 PM, Jan S Rellermeyer
> <rellermeyer at us.ibm.com> wrote:
>> I am helping people in IBM who have encountered a hotspot bug that surfaces
>> when using bitwise rotations (such as through Integer.rotateRight). I have
>> attached a small test program that illustrates the problem. When running
>> this on Power LE (I don't think that anybody tried on BE, though) the
>> results of the hash function are incorrect.
>>
>> The bug goes away when disabling inlining. After digging through the
>> generated code I found out that it contained some suspicious fnmadd
>> instructions where you would rather expect some kind of left rotate. I could
>> track down that the bug was caused by the immediate value for the right
>> shift constant of what should be a rlwinm node to be negative and thereby
>> bleeding into the opcode (which unfortunately still created a valid Power
>> instruction, namely the fnmadd). Running with a fastdebug build causes an
>> assertion to fail.
>>
>> The attached patch does fix the problem and so does an alternative patch
>> that replaces the URshift with a UShift but I am not entirely sure if this
>> really fixes the root cause or rather just prevents the rotlI instruction
>> from being matched by the ReduceInst.
>>
>> --Jan.
>>
>>
>> Dr. Jan S. Rellermeyer
>> IBM Research
>> RSM - Austin Research Lab
>> rellermeyer_at_us.ibm.com
>> The University of Texas at Austin
>> Adjunct Assistant Professor
>> jrellerm_at_cs.utexas.edu
>>
>> (See attached file: hash.java)(See attached file: rotl.patch)

From volker.simonis at gmail.com  Tue May 12 18:31:48 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 12 May 2015 20:31:48 +0200
Subject: hotspot: problem with bitwise rotation on PowerLE
In-Reply-To: <CA+3eh10ObFX-_A0ajkFC5P5yefbcTCFRMs_O=u=3HfZaazozNA@mail.gmail.com>
References: <OFF86722F2.508E098C-ON86257E3F.006CCF46-86257E3F.006E0494@us.ibm.com>
	<CAHQ51u4V=hzOv39oN7nPOwNfzBg6Sx_2_WMhgT3zPx+U=5Zo2g@mail.gmail.com>
	<CA+3eh10ObFX-_A0ajkFC5P5yefbcTCFRMs_O=u=3HfZaazozNA@mail.gmail.com>
Message-ID: <CA+3eh13V0gjpasBYHgaTWcZ76WRDFaT9j-6y8C6Hp8WXHMt+aA@mail.gmail.com>

Hi,

I think I've finally understood and fixed this issue.

The problem was that we initially took the "rotate left/right by 8-bit
immediate" instructions from x86_64. But on x86_64 the rotate
instructions for 32-bit integers do in fact really take 8-bit
immediates (seems like the Intel guys had to many spare bits when they
designed their instruction set :) On the other hand, the rotate
instructions on Power only use 5 bit to encode the rotation distance.

We do check for this limit, but only in the debug build. That's why
you saw the assertion in the fastdebug build.

I think the right solution for this problem is to simply mask the
rotation distance with 0x1f  (which is equivalent to taking the
distance modulo 32).

Can you please verify that the proposed fix also works for you on LE?

https://bugs.openjdk.java.net/browse/JDK-8080190
http://cr.openjdk.java.net/~simonis/webrevs/2015/8080190/

If yes I can send it out for review and push it to our jdk9 and jdk8u
repositories.

@Jan: have you signed the Oracle Contributor Agreement or are you
covered by the company-wide IBM OCA? I'd like to take your test as a
regresstion test into the OpenJDK HotSpot repository, but this is only
possible if you're a Contributor[2].

Thank you and best regards,
Volker

PS: the issue didn't appear in our internal SAP JVM version because we
already mask the inputs of the corresponding shift nodes in the ideal
graph but for some unknown reasons this shared changes haven?t been
contributed along with our ppc port so far.

[1] http://www.oracle.com/technetwork/community/oca-486395.html
[2] http://openjdk.java.net/bylaws#contributor


On Tue, May 12, 2015 at 2:38 PM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> Hi,
>
> this problem is not LE-related. I could reproduce it on BE as well. I
> also don't think that the fix proposed by Jan is completely right. I
> think it only helps because it leads to another instruction being
> matched. The problem is that the URshift has a negative input which
> should not be. It should have been converted to it's positive
> equivalent modulo 32 (as described in the  JLS 15.19 -
> https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.19).
>
> Strange enough, in our internal version, the error doesn't occur so I
> should actually easy find the difference. Unfortunately, I didn't saw
> it until now :(
> I'll keep you posted once I found out more...
>
> Regards,
> Volker
>
> On Tue, May 12, 2015 at 6:06 AM, Alexander Smundak <asmundak at google.com> wrote:
>> Looking into this. Sorry for the late response, we were moved into a
>> different office over the weekend.
>>
>> On Fri, May 8, 2015 at 1:01 PM, Jan S Rellermeyer
>> <rellermeyer at us.ibm.com> wrote:
>>> I am helping people in IBM who have encountered a hotspot bug that surfaces
>>> when using bitwise rotations (such as through Integer.rotateRight). I have
>>> attached a small test program that illustrates the problem. When running
>>> this on Power LE (I don't think that anybody tried on BE, though) the
>>> results of the hash function are incorrect.
>>>
>>> The bug goes away when disabling inlining. After digging through the
>>> generated code I found out that it contained some suspicious fnmadd
>>> instructions where you would rather expect some kind of left rotate. I could
>>> track down that the bug was caused by the immediate value for the right
>>> shift constant of what should be a rlwinm node to be negative and thereby
>>> bleeding into the opcode (which unfortunately still created a valid Power
>>> instruction, namely the fnmadd). Running with a fastdebug build causes an
>>> assertion to fail.
>>>
>>> The attached patch does fix the problem and so does an alternative patch
>>> that replaces the URshift with a UShift but I am not entirely sure if this
>>> really fixes the root cause or rather just prevents the rotlI instruction
>>> from being matched by the ReduceInst.
>>>
>>> --Jan.
>>>
>>>
>>> Dr. Jan S. Rellermeyer
>>> IBM Research
>>> RSM - Austin Research Lab
>>> rellermeyer_at_us.ibm.com
>>> The University of Texas at Austin
>>> Adjunct Assistant Professor
>>> jrellerm_at_cs.utexas.edu
>>>
>>> (See attached file: hash.java)(See attached file: rotl.patch)

From asmundak at google.com  Tue May 12 20:53:29 2015
From: asmundak at google.com (Alexander Smundak)
Date: Tue, 12 May 2015 13:53:29 -0700
Subject: hotspot: problem with bitwise rotation on PowerLE
In-Reply-To: <CA+3eh13V0gjpasBYHgaTWcZ76WRDFaT9j-6y8C6Hp8WXHMt+aA@mail.gmail.com>
References: <OFF86722F2.508E098C-ON86257E3F.006CCF46-86257E3F.006E0494@us.ibm.com>
	<CAHQ51u4V=hzOv39oN7nPOwNfzBg6Sx_2_WMhgT3zPx+U=5Zo2g@mail.gmail.com>
	<CA+3eh10ObFX-_A0ajkFC5P5yefbcTCFRMs_O=u=3HfZaazozNA@mail.gmail.com>
	<CA+3eh13V0gjpasBYHgaTWcZ76WRDFaT9j-6y8C6Hp8WXHMt+aA@mail.gmail.com>
Message-ID: <CAHQ51u4ZbnngDfN1KGPPSu7wZh_61CpadqDAq_-Z-rmVE1BopQ@mail.gmail.com>

I can confirm that the patch works. I tried to write the test that covers both
'rotlI_reg_immi8' and ' rotrI_reg_immi8' patterns but I didn't manage
to match the latter,
somehow all of the following methods inline to ROTLWI:

  static int rotateRight1(int i, int distance) { return (i >>>
distance) | (i << -distance); }
  static int rotateRight2(int i, int distance) { return (i <<
-distance) | (i >>> distance); }

These two inline to
    rotlwi Rx, Ry, (32-distance)

  static int rotateLeft1(int i, int distance) { return (i << distance)
| (i >>> -distance); }
  static int rotateLeft2(int i, int distance) { return (i >>>
-distance) | (i << distance); }
And these to inline to
    rotlwi Rx, Ry, distance

How can such a bug escape the hotspot test? I don't have access to
JCK, but isn't it supposed to cover this?

On Tue, May 12, 2015 at 11:31 AM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> Hi,
>
> I think I've finally understood and fixed this issue.
>
> The problem was that we initially took the "rotate left/right by 8-bit
> immediate" instructions from x86_64. But on x86_64 the rotate
> instructions for 32-bit integers do in fact really take 8-bit
> immediates (seems like the Intel guys had to many spare bits when they
> designed their instruction set :) On the other hand, the rotate
> instructions on Power only use 5 bit to encode the rotation distance.
>
> We do check for this limit, but only in the debug build. That's why
> you saw the assertion in the fastdebug build.
>
> I think the right solution for this problem is to simply mask the
> rotation distance with 0x1f  (which is equivalent to taking the
> distance modulo 32).
>
> Can you please verify that the proposed fix also works for you on LE?
>
> https://bugs.openjdk.java.net/browse/JDK-8080190
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8080190/
>
> If yes I can send it out for review and push it to our jdk9 and jdk8u
> repositories.
>
> @Jan: have you signed the Oracle Contributor Agreement or are you
> covered by the company-wide IBM OCA? I'd like to take your test as a
> regresstion test into the OpenJDK HotSpot repository, but this is only
> possible if you're a Contributor[2].
>
> Thank you and best regards,
> Volker
>
> PS: the issue didn't appear in our internal SAP JVM version because we
> already mask the inputs of the corresponding shift nodes in the ideal
> graph but for some unknown reasons this shared changes haven?t been
> contributed along with our ppc port so far.
>
> [1] http://www.oracle.com/technetwork/community/oca-486395.html
> [2] http://openjdk.java.net/bylaws#contributor
>
>
> On Tue, May 12, 2015 at 2:38 PM, Volker Simonis
> <volker.simonis at gmail.com> wrote:
>> Hi,
>>
>> this problem is not LE-related. I could reproduce it on BE as well. I
>> also don't think that the fix proposed by Jan is completely right. I
>> think it only helps because it leads to another instruction being
>> matched. The problem is that the URshift has a negative input which
>> should not be. It should have been converted to it's positive
>> equivalent modulo 32 (as described in the  JLS 15.19 -
>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.19).
>>
>> Strange enough, in our internal version, the error doesn't occur so I
>> should actually easy find the difference. Unfortunately, I didn't saw
>> it until now :(
>> I'll keep you posted once I found out more...
>>
>> Regards,
>> Volker
>>
>> On Tue, May 12, 2015 at 6:06 AM, Alexander Smundak <asmundak at google.com> wrote:
>>> Looking into this. Sorry for the late response, we were moved into a
>>> different office over the weekend.
>>>
>>> On Fri, May 8, 2015 at 1:01 PM, Jan S Rellermeyer
>>> <rellermeyer at us.ibm.com> wrote:
>>>> I am helping people in IBM who have encountered a hotspot bug that surfaces
>>>> when using bitwise rotations (such as through Integer.rotateRight). I have
>>>> attached a small test program that illustrates the problem. When running
>>>> this on Power LE (I don't think that anybody tried on BE, though) the
>>>> results of the hash function are incorrect.
>>>>
>>>> The bug goes away when disabling inlining. After digging through the
>>>> generated code I found out that it contained some suspicious fnmadd
>>>> instructions where you would rather expect some kind of left rotate. I could
>>>> track down that the bug was caused by the immediate value for the right
>>>> shift constant of what should be a rlwinm node to be negative and thereby
>>>> bleeding into the opcode (which unfortunately still created a valid Power
>>>> instruction, namely the fnmadd). Running with a fastdebug build causes an
>>>> assertion to fail.
>>>>
>>>> The attached patch does fix the problem and so does an alternative patch
>>>> that replaces the URshift with a UShift but I am not entirely sure if this
>>>> really fixes the root cause or rather just prevents the rotlI instruction
>>>> from being matched by the ReduceInst.
>>>>
>>>> --Jan.
>>>>
>>>>
>>>> Dr. Jan S. Rellermeyer
>>>> IBM Research
>>>> RSM - Austin Research Lab
>>>> rellermeyer_at_us.ibm.com
>>>> The University of Texas at Austin
>>>> Adjunct Assistant Professor
>>>> jrellerm_at_cs.utexas.edu
>>>>
>>>> (See attached file: hash.java)(See attached file: rotl.patch)

From rellermeyer at us.ibm.com  Tue May 12 21:17:41 2015
From: rellermeyer at us.ibm.com (Jan S Rellermeyer)
Date: Tue, 12 May 2015 16:17:41 -0500
Subject: hotspot: problem with bitwise rotation on PowerLE
In-Reply-To: <CAHQ51u4ZbnngDfN1KGPPSu7wZh_61CpadqDAq_-Z-rmVE1BopQ@mail.gmail.com>
References: <OFF86722F2.508E098C-ON86257E3F.006CCF46-86257E3F.006E0494@us.ibm.com>	<CAHQ51u4V=hzOv39oN7nPOwNfzBg6Sx_2_WMhgT3zPx+U=5Zo2g@mail.gmail.com>
	<CA+3eh10ObFX-_A0ajkFC5P5yefbcTCFRMs_O=u=3HfZaazozNA@mail.gmail.com>	<CA+3eh13V0gjpasBYHgaTWcZ76WRDFaT9j-6y8C6Hp8WXHMt+aA@mail.gmail.com>
	<CAHQ51u4ZbnngDfN1KGPPSu7wZh_61CpadqDAq_-Z-rmVE1BopQ@mail.gmail.com>
Message-ID: <OF51E2D972.253ABEBB-ON86257E43.007497B3-86257E43.0074F9F3@us.ibm.com>

I have also been able test the patch in our setup and it works. Thanks for
figuring this out.

Do you happen to know when the next 8 update release is scheduled that
would contain the fix?

Regarding coverage by the IBM OCA and the ability to contribute the hash
code for regression testing, I am checking this right now with the people
who passed the code on to me.

--Jan.



From:	Alexander Smundak <asmundak at google.com>
To:	Volker Simonis <volker.simonis at gmail.com>
Cc:	Jan S Rellermeyer/Austin/IBM at IBMUS,
            "ppc-aix-port-dev at openjdk.java.net"
            <ppc-aix-port-dev at openjdk.java.net>
Date:	05/12/2015 03:59 PM
Subject:	Re: hotspot: problem with bitwise rotation on PowerLE



I can confirm that the patch works. I tried to write the test that covers
both
'rotlI_reg_immi8' and ' rotrI_reg_immi8' patterns but I didn't manage
to match the latter,
somehow all of the following methods inline to ROTLWI:

  static int rotateRight1(int i, int distance) { return (i >>>
distance) | (i << -distance); }
  static int rotateRight2(int i, int distance) { return (i <<
-distance) | (i >>> distance); }

These two inline to
    rotlwi Rx, Ry, (32-distance)

  static int rotateLeft1(int i, int distance) { return (i << distance)
| (i >>> -distance); }
  static int rotateLeft2(int i, int distance) { return (i >>>
-distance) | (i << distance); }
And these to inline to
    rotlwi Rx, Ry, distance

How can such a bug escape the hotspot test? I don't have access to
JCK, but isn't it supposed to cover this?

On Tue, May 12, 2015 at 11:31 AM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> Hi,
>
> I think I've finally understood and fixed this issue.
>
> The problem was that we initially took the "rotate left/right by 8-bit
> immediate" instructions from x86_64. But on x86_64 the rotate
> instructions for 32-bit integers do in fact really take 8-bit
> immediates (seems like the Intel guys had to many spare bits when they
> designed their instruction set :) On the other hand, the rotate
> instructions on Power only use 5 bit to encode the rotation distance.
>
> We do check for this limit, but only in the debug build. That's why
> you saw the assertion in the fastdebug build.
>
> I think the right solution for this problem is to simply mask the
> rotation distance with 0x1f  (which is equivalent to taking the
> distance modulo 32).
>
> Can you please verify that the proposed fix also works for you on LE?
>
> https://bugs.openjdk.java.net/browse/JDK-8080190
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8080190/
>
> If yes I can send it out for review and push it to our jdk9 and jdk8u
> repositories.
>
> @Jan: have you signed the Oracle Contributor Agreement or are you
> covered by the company-wide IBM OCA? I'd like to take your test as a
> regresstion test into the OpenJDK HotSpot repository, but this is only
> possible if you're a Contributor[2].
>
> Thank you and best regards,
> Volker
>
> PS: the issue didn't appear in our internal SAP JVM version because we
> already mask the inputs of the corresponding shift nodes in the ideal
> graph but for some unknown reasons this shared changes haven?t been
> contributed along with our ppc port so far.
>
> [1] http://www.oracle.com/technetwork/community/oca-486395.html
> [2] http://openjdk.java.net/bylaws#contributor
>
>
> On Tue, May 12, 2015 at 2:38 PM, Volker Simonis
> <volker.simonis at gmail.com> wrote:
>> Hi,
>>
>> this problem is not LE-related. I could reproduce it on BE as well. I
>> also don't think that the fix proposed by Jan is completely right. I
>> think it only helps because it leads to another instruction being
>> matched. The problem is that the URshift has a negative input which
>> should not be. It should have been converted to it's positive
>> equivalent modulo 32 (as described in the  JLS 15.19 -
>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.19
).
>>
>> Strange enough, in our internal version, the error doesn't occur so I
>> should actually easy find the difference. Unfortunately, I didn't saw
>> it until now :(
>> I'll keep you posted once I found out more...
>>
>> Regards,
>> Volker
>>
>> On Tue, May 12, 2015 at 6:06 AM, Alexander Smundak <asmundak at google.com>
wrote:
>>> Looking into this. Sorry for the late response, we were moved into a
>>> different office over the weekend.
>>>
>>> On Fri, May 8, 2015 at 1:01 PM, Jan S Rellermeyer
>>> <rellermeyer at us.ibm.com> wrote:
>>>> I am helping people in IBM who have encountered a hotspot bug that
surfaces
>>>> when using bitwise rotations (such as through Integer.rotateRight). I
have
>>>> attached a small test program that illustrates the problem. When
running
>>>> this on Power LE (I don't think that anybody tried on BE, though) the
>>>> results of the hash function are incorrect.
>>>>
>>>> The bug goes away when disabling inlining. After digging through the
>>>> generated code I found out that it contained some suspicious fnmadd
>>>> instructions where you would rather expect some kind of left rotate. I
could
>>>> track down that the bug was caused by the immediate value for the
right
>>>> shift constant of what should be a rlwinm node to be negative and
thereby
>>>> bleeding into the opcode (which unfortunately still created a valid
Power
>>>> instruction, namely the fnmadd). Running with a fastdebug build causes
an
>>>> assertion to fail.
>>>>
>>>> The attached patch does fix the problem and so does an alternative
patch
>>>> that replaces the URshift with a UShift but I am not entirely sure if
this
>>>> really fixes the root cause or rather just prevents the rotlI
instruction
>>>> from being matched by the ReduceInst.
>>>>
>>>> --Jan.
>>>>
>>>>
>>>> Dr. Jan S. Rellermeyer
>>>> IBM Research
>>>> RSM - Austin Research Lab
>>>> rellermeyer_at_us.ibm.com
>>>> The University of Texas at Austin
>>>> Adjunct Assistant Professor
>>>> jrellerm_at_cs.utexas.edu
>>>>
>>>> (See attached file: hash.java)(See attached file: rotl.patch)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20150512/ad554742/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20150512/ad554742/graycol-0001.gif>

From asmundak at google.com  Tue May 12 22:34:14 2015
From: asmundak at google.com (Alexander Smundak)
Date: Tue, 12 May 2015 15:34:14 -0700
Subject: hotspot: problem with bitwise rotation on PowerLE
In-Reply-To: <OF51E2D972.253ABEBB-ON86257E43.007497B3-86257E43.0074F9F3@us.ibm.com>
References: <OFF86722F2.508E098C-ON86257E3F.006CCF46-86257E3F.006E0494@us.ibm.com>
	<CAHQ51u4V=hzOv39oN7nPOwNfzBg6Sx_2_WMhgT3zPx+U=5Zo2g@mail.gmail.com>
	<CA+3eh10ObFX-_A0ajkFC5P5yefbcTCFRMs_O=u=3HfZaazozNA@mail.gmail.com>
	<CA+3eh13V0gjpasBYHgaTWcZ76WRDFaT9j-6y8C6Hp8WXHMt+aA@mail.gmail.com>
	<CAHQ51u4ZbnngDfN1KGPPSu7wZh_61CpadqDAq_-Z-rmVE1BopQ@mail.gmail.com>
	<OF51E2D972.253ABEBB-ON86257E43.007497B3-86257E43.0074F9F3@us.ibm.com>
Message-ID: <CAHQ51u44VxV27vz-9NR8ztkGG8ToJ1z+ubdyqP4=nL4ujq9RPQ@mail.gmail.com>

I have somewhat more isolated test (just calling
rotateRigth/rotateLeft methods from my previous e-mail with constant
distance argument that reveals the problem. Please let me know if you
are interested.

On Tue, May 12, 2015 at 2:17 PM, Jan S Rellermeyer
<rellermeyer at us.ibm.com> wrote:
> I have also been able test the patch in our setup and it works. Thanks for
> figuring this out.
>
> Do you happen to know when the next 8 update release is scheduled that would
> contain the fix?
>
> Regarding coverage by the IBM OCA and the ability to contribute the hash
> code for regression testing, I am checking this right now with the people
> who passed the code on to me.
>
> --Jan.
>
> Alexander Smundak ---05/12/2015 03:59:48 PM---I can confirm that the patch
> works. I tried to write the test that covers both 'rotlI_reg_immi8' and
>
> From: Alexander Smundak <asmundak at google.com>
> To: Volker Simonis <volker.simonis at gmail.com>
> Cc: Jan S Rellermeyer/Austin/IBM at IBMUS, "ppc-aix-port-dev at openjdk.java.net"
> <ppc-aix-port-dev at openjdk.java.net>
> Date: 05/12/2015 03:59 PM
> Subject: Re: hotspot: problem with bitwise rotation on PowerLE
>
> ________________________________
>
>
>
> I can confirm that the patch works. I tried to write the test that covers
> both
> 'rotlI_reg_immi8' and ' rotrI_reg_immi8' patterns but I didn't manage
> to match the latter,
> somehow all of the following methods inline to ROTLWI:
>
>  static int rotateRight1(int i, int distance) { return (i >>>
> distance) | (i << -distance); }
>  static int rotateRight2(int i, int distance) { return (i <<
> -distance) | (i >>> distance); }
>
> These two inline to
>    rotlwi Rx, Ry, (32-distance)
>
>  static int rotateLeft1(int i, int distance) { return (i << distance)
> | (i >>> -distance); }
>  static int rotateLeft2(int i, int distance) { return (i >>>
> -distance) | (i << distance); }
> And these to inline to
>    rotlwi Rx, Ry, distance
>
> How can such a bug escape the hotspot test? I don't have access to
> JCK, but isn't it supposed to cover this?
>
> On Tue, May 12, 2015 at 11:31 AM, Volker Simonis
> <volker.simonis at gmail.com> wrote:
>> Hi,
>>
>> I think I've finally understood and fixed this issue.
>>
>> The problem was that we initially took the "rotate left/right by 8-bit
>> immediate" instructions from x86_64. But on x86_64 the rotate
>> instructions for 32-bit integers do in fact really take 8-bit
>> immediates (seems like the Intel guys had to many spare bits when they
>> designed their instruction set :) On the other hand, the rotate
>> instructions on Power only use 5 bit to encode the rotation distance.
>>
>> We do check for this limit, but only in the debug build. That's why
>> you saw the assertion in the fastdebug build.
>>
>> I think the right solution for this problem is to simply mask the
>> rotation distance with 0x1f  (which is equivalent to taking the
>> distance modulo 32).
>>
>> Can you please verify that the proposed fix also works for you on LE?
>>
>> https://bugs.openjdk.java.net/browse/JDK-8080190
>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8080190/
>>
>> If yes I can send it out for review and push it to our jdk9 and jdk8u
>> repositories.
>>
>> @Jan: have you signed the Oracle Contributor Agreement or are you
>> covered by the company-wide IBM OCA? I'd like to take your test as a
>> regresstion test into the OpenJDK HotSpot repository, but this is only
>> possible if you're a Contributor[2].
>>
>> Thank you and best regards,
>> Volker
>>
>> PS: the issue didn't appear in our internal SAP JVM version because we
>> already mask the inputs of the corresponding shift nodes in the ideal
>> graph but for some unknown reasons this shared changes haven?t been
>> contributed along with our ppc port so far.
>>
>> [1] http://www.oracle.com/technetwork/community/oca-486395.html
>> [2] http://openjdk.java.net/bylaws#contributor
>>
>>
>> On Tue, May 12, 2015 at 2:38 PM, Volker Simonis
>> <volker.simonis at gmail.com> wrote:
>>> Hi,
>>>
>>> this problem is not LE-related. I could reproduce it on BE as well. I
>>> also don't think that the fix proposed by Jan is completely right. I
>>> think it only helps because it leads to another instruction being
>>> matched. The problem is that the URshift has a negative input which
>>> should not be. It should have been converted to it's positive
>>> equivalent modulo 32 (as described in the  JLS 15.19 -
>>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.19).
>>>
>>> Strange enough, in our internal version, the error doesn't occur so I
>>> should actually easy find the difference. Unfortunately, I didn't saw
>>> it until now :(
>>> I'll keep you posted once I found out more...
>>>
>>> Regards,
>>> Volker
>>>
>>> On Tue, May 12, 2015 at 6:06 AM, Alexander Smundak <asmundak at google.com>
>>> wrote:
>>>> Looking into this. Sorry for the late response, we were moved into a
>>>> different office over the weekend.
>>>>
>>>> On Fri, May 8, 2015 at 1:01 PM, Jan S Rellermeyer
>>>> <rellermeyer at us.ibm.com> wrote:
>>>>> I am helping people in IBM who have encountered a hotspot bug that
>>>>> surfaces
>>>>> when using bitwise rotations (such as through Integer.rotateRight). I
>>>>> have
>>>>> attached a small test program that illustrates the problem. When
>>>>> running
>>>>> this on Power LE (I don't think that anybody tried on BE, though) the
>>>>> results of the hash function are incorrect.
>>>>>
>>>>> The bug goes away when disabling inlining. After digging through the
>>>>> generated code I found out that it contained some suspicious fnmadd
>>>>> instructions where you would rather expect some kind of left rotate. I
>>>>> could
>>>>> track down that the bug was caused by the immediate value for the right
>>>>> shift constant of what should be a rlwinm node to be negative and
>>>>> thereby
>>>>> bleeding into the opcode (which unfortunately still created a valid
>>>>> Power
>>>>> instruction, namely the fnmadd). Running with a fastdebug build causes
>>>>> an
>>>>> assertion to fail.
>>>>>
>>>>> The attached patch does fix the problem and so does an alternative
>>>>> patch
>>>>> that replaces the URshift with a UShift but I am not entirely sure if
>>>>> this
>>>>> really fixes the root cause or rather just prevents the rotlI
>>>>> instruction
>>>>> from being matched by the ReduceInst.
>>>>>
>>>>> --Jan.
>>>>>
>>>>>
>>>>> Dr. Jan S. Rellermeyer
>>>>> IBM Research
>>>>> RSM - Austin Research Lab
>>>>> rellermeyer_at_us.ibm.com
>>>>> The University of Texas at Austin
>>>>> Adjunct Assistant Professor
>>>>> jrellerm_at_cs.utexas.edu
>>>>>
>>>>> (See attached file: hash.java)(See attached file: rotl.patch)
>
>
>

From volker.simonis at gmail.com  Wed May 13 09:34:19 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 13 May 2015 11:34:19 +0200
Subject: hotspot: problem with bitwise rotation on PowerLE
In-Reply-To: <CAHQ51u4ZbnngDfN1KGPPSu7wZh_61CpadqDAq_-Z-rmVE1BopQ@mail.gmail.com>
References: <OFF86722F2.508E098C-ON86257E3F.006CCF46-86257E3F.006E0494@us.ibm.com>
	<CAHQ51u4V=hzOv39oN7nPOwNfzBg6Sx_2_WMhgT3zPx+U=5Zo2g@mail.gmail.com>
	<CA+3eh10ObFX-_A0ajkFC5P5yefbcTCFRMs_O=u=3HfZaazozNA@mail.gmail.com>
	<CA+3eh13V0gjpasBYHgaTWcZ76WRDFaT9j-6y8C6Hp8WXHMt+aA@mail.gmail.com>
	<CAHQ51u4ZbnngDfN1KGPPSu7wZh_61CpadqDAq_-Z-rmVE1BopQ@mail.gmail.com>
Message-ID: <CA+3eh13vbLijYpuWzzMdtwNGPzBVU2wRbE5CW2RA1KUbM_L2dA@mail.gmail.com>

On Tue, May 12, 2015 at 10:53 PM, Alexander Smundak <asmundak at google.com> wrote:
> I can confirm that the patch works. I tried to write the test that covers both
> 'rotlI_reg_immi8' and ' rotrI_reg_immi8' patterns but I didn't manage
> to match the latter,
> somehow all of the following methods inline to ROTLWI:
>
>   static int rotateRight1(int i, int distance) { return (i >>>
> distance) | (i << -distance); }
>   static int rotateRight2(int i, int distance) { return (i <<
> -distance) | (i >>> distance); }
>
> These two inline to
>     rotlwi Rx, Ry, (32-distance)
>
>   static int rotateLeft1(int i, int distance) { return (i << distance)
> | (i >>> -distance); }
>   static int rotateLeft2(int i, int distance) { return (i >>>
> -distance) | (i << distance); }
> And these to inline to
>     rotlwi Rx, Ry, distance
>

That's because ADLC is 'smart'. For the instruction 'rotlI_reg_immi8'
it generates two nodes, one with the verbatim match rule:

match(Set dst (OrI (LShiftI src lshift) (URShiftI src rshift)))

and another one with the rule:

match(Set dst (OrI (URShiftI src rshift) (LShiftI src lshift)))

This is because ADLC knows that "or" is commutative and automatically
generates nodes for both variants of the "or" clause to save us from
having to provide both versions manually. But in this case it happens
that the second version is equal to the matching pattern of
'rotrI_reg_immi8', so that one will never match.

> How can such a bug escape the hotspot test? I don't have access to
> JCK, but isn't it supposed to cover this?
>

It's a common misunderstanding that passing the JCK is a quality
statement. The JCK is merely a conformance test suite - it doesn't
check the performance, robustness or general stability of the VM under
test. There is for sure a test for Integer.rotateLeft() in the test
suite, but remember that for this error to occur, Integer.rotateLeft()
has to be called with immediates and it has to be called often enough
such that it gets compiled on C2 level.

> On Tue, May 12, 2015 at 11:31 AM, Volker Simonis
> <volker.simonis at gmail.com> wrote:
>> Hi,
>>
>> I think I've finally understood and fixed this issue.
>>
>> The problem was that we initially took the "rotate left/right by 8-bit
>> immediate" instructions from x86_64. But on x86_64 the rotate
>> instructions for 32-bit integers do in fact really take 8-bit
>> immediates (seems like the Intel guys had to many spare bits when they
>> designed their instruction set :) On the other hand, the rotate
>> instructions on Power only use 5 bit to encode the rotation distance.
>>
>> We do check for this limit, but only in the debug build. That's why
>> you saw the assertion in the fastdebug build.
>>
>> I think the right solution for this problem is to simply mask the
>> rotation distance with 0x1f  (which is equivalent to taking the
>> distance modulo 32).
>>
>> Can you please verify that the proposed fix also works for you on LE?
>>
>> https://bugs.openjdk.java.net/browse/JDK-8080190
>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8080190/
>>
>> If yes I can send it out for review and push it to our jdk9 and jdk8u
>> repositories.
>>
>> @Jan: have you signed the Oracle Contributor Agreement or are you
>> covered by the company-wide IBM OCA? I'd like to take your test as a
>> regresstion test into the OpenJDK HotSpot repository, but this is only
>> possible if you're a Contributor[2].
>>
>> Thank you and best regards,
>> Volker
>>
>> PS: the issue didn't appear in our internal SAP JVM version because we
>> already mask the inputs of the corresponding shift nodes in the ideal
>> graph but for some unknown reasons this shared changes haven?t been
>> contributed along with our ppc port so far.
>>
>> [1] http://www.oracle.com/technetwork/community/oca-486395.html
>> [2] http://openjdk.java.net/bylaws#contributor
>>
>>
>> On Tue, May 12, 2015 at 2:38 PM, Volker Simonis
>> <volker.simonis at gmail.com> wrote:
>>> Hi,
>>>
>>> this problem is not LE-related. I could reproduce it on BE as well. I
>>> also don't think that the fix proposed by Jan is completely right. I
>>> think it only helps because it leads to another instruction being
>>> matched. The problem is that the URshift has a negative input which
>>> should not be. It should have been converted to it's positive
>>> equivalent modulo 32 (as described in the  JLS 15.19 -
>>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.19).
>>>
>>> Strange enough, in our internal version, the error doesn't occur so I
>>> should actually easy find the difference. Unfortunately, I didn't saw
>>> it until now :(
>>> I'll keep you posted once I found out more...
>>>
>>> Regards,
>>> Volker
>>>
>>> On Tue, May 12, 2015 at 6:06 AM, Alexander Smundak <asmundak at google.com> wrote:
>>>> Looking into this. Sorry for the late response, we were moved into a
>>>> different office over the weekend.
>>>>
>>>> On Fri, May 8, 2015 at 1:01 PM, Jan S Rellermeyer
>>>> <rellermeyer at us.ibm.com> wrote:
>>>>> I am helping people in IBM who have encountered a hotspot bug that surfaces
>>>>> when using bitwise rotations (such as through Integer.rotateRight). I have
>>>>> attached a small test program that illustrates the problem. When running
>>>>> this on Power LE (I don't think that anybody tried on BE, though) the
>>>>> results of the hash function are incorrect.
>>>>>
>>>>> The bug goes away when disabling inlining. After digging through the
>>>>> generated code I found out that it contained some suspicious fnmadd
>>>>> instructions where you would rather expect some kind of left rotate. I could
>>>>> track down that the bug was caused by the immediate value for the right
>>>>> shift constant of what should be a rlwinm node to be negative and thereby
>>>>> bleeding into the opcode (which unfortunately still created a valid Power
>>>>> instruction, namely the fnmadd). Running with a fastdebug build causes an
>>>>> assertion to fail.
>>>>>
>>>>> The attached patch does fix the problem and so does an alternative patch
>>>>> that replaces the URshift with a UShift but I am not entirely sure if this
>>>>> really fixes the root cause or rather just prevents the rotlI instruction
>>>>> from being matched by the ReduceInst.
>>>>>
>>>>> --Jan.
>>>>>
>>>>>
>>>>> Dr. Jan S. Rellermeyer
>>>>> IBM Research
>>>>> RSM - Austin Research Lab
>>>>> rellermeyer_at_us.ibm.com
>>>>> The University of Texas at Austin
>>>>> Adjunct Assistant Professor
>>>>> jrellerm_at_cs.utexas.edu
>>>>>
>>>>> (See attached file: hash.java)(See attached file: rotl.patch)

From volker.simonis at gmail.com  Wed May 13 09:36:40 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 13 May 2015 11:36:40 +0200
Subject: hotspot: problem with bitwise rotation on PowerLE
In-Reply-To: <CAHQ51u44VxV27vz-9NR8ztkGG8ToJ1z+ubdyqP4=nL4ujq9RPQ@mail.gmail.com>
References: <OFF86722F2.508E098C-ON86257E3F.006CCF46-86257E3F.006E0494@us.ibm.com>
	<CAHQ51u4V=hzOv39oN7nPOwNfzBg6Sx_2_WMhgT3zPx+U=5Zo2g@mail.gmail.com>
	<CA+3eh10ObFX-_A0ajkFC5P5yefbcTCFRMs_O=u=3HfZaazozNA@mail.gmail.com>
	<CA+3eh13V0gjpasBYHgaTWcZ76WRDFaT9j-6y8C6Hp8WXHMt+aA@mail.gmail.com>
	<CAHQ51u4ZbnngDfN1KGPPSu7wZh_61CpadqDAq_-Z-rmVE1BopQ@mail.gmail.com>
	<OF51E2D972.253ABEBB-ON86257E43.007497B3-86257E43.0074F9F3@us.ibm.com>
	<CAHQ51u44VxV27vz-9NR8ztkGG8ToJ1z+ubdyqP4=nL4ujq9RPQ@mail.gmail.com>
Message-ID: <CA+3eh11FuXooZWc6N5TAUUGLtmBMoAnRWP2=1ZXLBMMq3K1j4A@mail.gmail.com>

Thanks, but I've already written a minimal test case myself.

I just asked for including the initial test by Jan because it also
exercises some other interesting parts of the optimizer and may thus
be a valuable test case in itself.

Regards,
Volker


On Wed, May 13, 2015 at 12:34 AM, Alexander Smundak <asmundak at google.com> wrote:
> I have somewhat more isolated test (just calling
> rotateRigth/rotateLeft methods from my previous e-mail with constant
> distance argument that reveals the problem. Please let me know if you
> are interested.
>
> On Tue, May 12, 2015 at 2:17 PM, Jan S Rellermeyer
> <rellermeyer at us.ibm.com> wrote:
>> I have also been able test the patch in our setup and it works. Thanks for
>> figuring this out.
>>
>> Do you happen to know when the next 8 update release is scheduled that would
>> contain the fix?
>>
>> Regarding coverage by the IBM OCA and the ability to contribute the hash
>> code for regression testing, I am checking this right now with the people
>> who passed the code on to me.
>>
>> --Jan.
>>
>> Alexander Smundak ---05/12/2015 03:59:48 PM---I can confirm that the patch
>> works. I tried to write the test that covers both 'rotlI_reg_immi8' and
>>
>> From: Alexander Smundak <asmundak at google.com>
>> To: Volker Simonis <volker.simonis at gmail.com>
>> Cc: Jan S Rellermeyer/Austin/IBM at IBMUS, "ppc-aix-port-dev at openjdk.java.net"
>> <ppc-aix-port-dev at openjdk.java.net>
>> Date: 05/12/2015 03:59 PM
>> Subject: Re: hotspot: problem with bitwise rotation on PowerLE
>>
>> ________________________________
>>
>>
>>
>> I can confirm that the patch works. I tried to write the test that covers
>> both
>> 'rotlI_reg_immi8' and ' rotrI_reg_immi8' patterns but I didn't manage
>> to match the latter,
>> somehow all of the following methods inline to ROTLWI:
>>
>>  static int rotateRight1(int i, int distance) { return (i >>>
>> distance) | (i << -distance); }
>>  static int rotateRight2(int i, int distance) { return (i <<
>> -distance) | (i >>> distance); }
>>
>> These two inline to
>>    rotlwi Rx, Ry, (32-distance)
>>
>>  static int rotateLeft1(int i, int distance) { return (i << distance)
>> | (i >>> -distance); }
>>  static int rotateLeft2(int i, int distance) { return (i >>>
>> -distance) | (i << distance); }
>> And these to inline to
>>    rotlwi Rx, Ry, distance
>>
>> How can such a bug escape the hotspot test? I don't have access to
>> JCK, but isn't it supposed to cover this?
>>
>> On Tue, May 12, 2015 at 11:31 AM, Volker Simonis
>> <volker.simonis at gmail.com> wrote:
>>> Hi,
>>>
>>> I think I've finally understood and fixed this issue.
>>>
>>> The problem was that we initially took the "rotate left/right by 8-bit
>>> immediate" instructions from x86_64. But on x86_64 the rotate
>>> instructions for 32-bit integers do in fact really take 8-bit
>>> immediates (seems like the Intel guys had to many spare bits when they
>>> designed their instruction set :) On the other hand, the rotate
>>> instructions on Power only use 5 bit to encode the rotation distance.
>>>
>>> We do check for this limit, but only in the debug build. That's why
>>> you saw the assertion in the fastdebug build.
>>>
>>> I think the right solution for this problem is to simply mask the
>>> rotation distance with 0x1f  (which is equivalent to taking the
>>> distance modulo 32).
>>>
>>> Can you please verify that the proposed fix also works for you on LE?
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8080190
>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8080190/
>>>
>>> If yes I can send it out for review and push it to our jdk9 and jdk8u
>>> repositories.
>>>
>>> @Jan: have you signed the Oracle Contributor Agreement or are you
>>> covered by the company-wide IBM OCA? I'd like to take your test as a
>>> regresstion test into the OpenJDK HotSpot repository, but this is only
>>> possible if you're a Contributor[2].
>>>
>>> Thank you and best regards,
>>> Volker
>>>
>>> PS: the issue didn't appear in our internal SAP JVM version because we
>>> already mask the inputs of the corresponding shift nodes in the ideal
>>> graph but for some unknown reasons this shared changes haven?t been
>>> contributed along with our ppc port so far.
>>>
>>> [1] http://www.oracle.com/technetwork/community/oca-486395.html
>>> [2] http://openjdk.java.net/bylaws#contributor
>>>
>>>
>>> On Tue, May 12, 2015 at 2:38 PM, Volker Simonis
>>> <volker.simonis at gmail.com> wrote:
>>>> Hi,
>>>>
>>>> this problem is not LE-related. I could reproduce it on BE as well. I
>>>> also don't think that the fix proposed by Jan is completely right. I
>>>> think it only helps because it leads to another instruction being
>>>> matched. The problem is that the URshift has a negative input which
>>>> should not be. It should have been converted to it's positive
>>>> equivalent modulo 32 (as described in the  JLS 15.19 -
>>>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.19).
>>>>
>>>> Strange enough, in our internal version, the error doesn't occur so I
>>>> should actually easy find the difference. Unfortunately, I didn't saw
>>>> it until now :(
>>>> I'll keep you posted once I found out more...
>>>>
>>>> Regards,
>>>> Volker
>>>>
>>>> On Tue, May 12, 2015 at 6:06 AM, Alexander Smundak <asmundak at google.com>
>>>> wrote:
>>>>> Looking into this. Sorry for the late response, we were moved into a
>>>>> different office over the weekend.
>>>>>
>>>>> On Fri, May 8, 2015 at 1:01 PM, Jan S Rellermeyer
>>>>> <rellermeyer at us.ibm.com> wrote:
>>>>>> I am helping people in IBM who have encountered a hotspot bug that
>>>>>> surfaces
>>>>>> when using bitwise rotations (such as through Integer.rotateRight). I
>>>>>> have
>>>>>> attached a small test program that illustrates the problem. When
>>>>>> running
>>>>>> this on Power LE (I don't think that anybody tried on BE, though) the
>>>>>> results of the hash function are incorrect.
>>>>>>
>>>>>> The bug goes away when disabling inlining. After digging through the
>>>>>> generated code I found out that it contained some suspicious fnmadd
>>>>>> instructions where you would rather expect some kind of left rotate. I
>>>>>> could
>>>>>> track down that the bug was caused by the immediate value for the right
>>>>>> shift constant of what should be a rlwinm node to be negative and
>>>>>> thereby
>>>>>> bleeding into the opcode (which unfortunately still created a valid
>>>>>> Power
>>>>>> instruction, namely the fnmadd). Running with a fastdebug build causes
>>>>>> an
>>>>>> assertion to fail.
>>>>>>
>>>>>> The attached patch does fix the problem and so does an alternative
>>>>>> patch
>>>>>> that replaces the URshift with a UShift but I am not entirely sure if
>>>>>> this
>>>>>> really fixes the root cause or rather just prevents the rotlI
>>>>>> instruction
>>>>>> from being matched by the ReduceInst.
>>>>>>
>>>>>> --Jan.
>>>>>>
>>>>>>
>>>>>> Dr. Jan S. Rellermeyer
>>>>>> IBM Research
>>>>>> RSM - Austin Research Lab
>>>>>> rellermeyer_at_us.ibm.com
>>>>>> The University of Texas at Austin
>>>>>> Adjunct Assistant Professor
>>>>>> jrellerm_at_cs.utexas.edu
>>>>>>
>>>>>> (See attached file: hash.java)(See attached file: rotl.patch)
>>
>>
>>

From volker.simonis at gmail.com  Wed May 13 16:29:27 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 13 May 2015 18:29:27 +0200
Subject: RFR(S): 8080190: PPC64: Fix wrong rotate instructions in the .ad file
Message-ID: <CA+3eh13agOYGrDRY8-ENrKzh1Xe+tFRsz-0_uKbOpbJwVzM_SA@mail.gmail.com>

Hi,

could you please review the following, ppc64-only fix which solves a
problem with the integer-rotate instructions in C2:

https://bugs.openjdk.java.net/browse/JDK-8080190
http://cr.openjdk.java.net/~simonis/webrevs/2015/8080190.v2/

The problem was that we initially took the "rotate left/right by 8-bit
immediate" instructions from x86_64. But on x86_64 the rotate
instructions for 32-bit integers do in fact really take 8-bit
immediates (seems like the Intel guys had to many spare bits when they
designed their instruction set :) On the other hand, the rotate
instructions on Power only use 5 bit to encode the rotation distance.

We do check for this limit, but only in the debug build so you'll see
an assertion there, but in the product build we will silently emit a
wrong instruction which can lead to anything starting from a crash up
to an incorrect computation.

I think the simplest solution for this problem is to mask the
rotation distance with 0x1f  (which is equivalent to taking the
distance modulo 32) in the corresponding instructions.

This change should also be backported to 8 as fast as possible. Notice
that this a day-zero bug in our ppc64 port because in our internal SAP
JVM we already mask the shift amounts in the ideal graph but for some
unknown reasons these shared changes haven?t been contributed along
with our port.

Thank you and best regards,
Volker

From vladimir.kozlov at oracle.com  Wed May 13 18:39:05 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Wed, 13 May 2015 11:39:05 -0700
Subject: RFR(S): 8080190: PPC64: Fix wrong rotate instructions in the
	.ad file
In-Reply-To: <CA+3eh13agOYGrDRY8-ENrKzh1Xe+tFRsz-0_uKbOpbJwVzM_SA@mail.gmail.com>
References: <CA+3eh13agOYGrDRY8-ENrKzh1Xe+tFRsz-0_uKbOpbJwVzM_SA@mail.gmail.com>
Message-ID: <55539A49.4010906@oracle.com>

Is this because you can have negative values?
I see that at the bottom of calls which generate bits u_field() method 
is used. Why not mask it there?

There are other instructions which can have the same problem (slwi). You 
would have to guarantee all of those do the masking. That is why I am 
asking why not mask it at the final code methods, like u_field()?

Thanks,
Vladimir

On 5/13/15 9:29 AM, Volker Simonis wrote:
> Hi,
>
> could you please review the following, ppc64-only fix which solves a
> problem with the integer-rotate instructions in C2:
>
> https://bugs.openjdk.java.net/browse/JDK-8080190
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8080190.v2/
>
> The problem was that we initially took the "rotate left/right by 8-bit
> immediate" instructions from x86_64. But on x86_64 the rotate
> instructions for 32-bit integers do in fact really take 8-bit
> immediates (seems like the Intel guys had to many spare bits when they
> designed their instruction set :) On the other hand, the rotate
> instructions on Power only use 5 bit to encode the rotation distance.
>
> We do check for this limit, but only in the debug build so you'll see
> an assertion there, but in the product build we will silently emit a
> wrong instruction which can lead to anything starting from a crash up
> to an incorrect computation.
>
> I think the simplest solution for this problem is to mask the
> rotation distance with 0x1f  (which is equivalent to taking the
> distance modulo 32) in the corresponding instructions.
>
> This change should also be backported to 8 as fast as possible. Notice
> that this a day-zero bug in our ppc64 port because in our internal SAP
> JVM we already mask the shift amounts in the ideal graph but for some
> unknown reasons these shared changes haven?t been contributed along
> with our port.
>
> Thank you and best regards,
> Volker
>

From volker.simonis at gmail.com  Mon May 18 16:05:04 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 18 May 2015 18:05:04 +0200
Subject: RFR(S): 8080190: PPC64: Fix wrong rotate instructions in the .ad
	file
In-Reply-To: <55539A49.4010906@oracle.com>
References: <CA+3eh13agOYGrDRY8-ENrKzh1Xe+tFRsz-0_uKbOpbJwVzM_SA@mail.gmail.com>
	<55539A49.4010906@oracle.com>
Message-ID: <CA+3eh11MPV+tHXrtWN9teya7b=4O-iitU3pvuA3Yxa9s43SL4A@mail.gmail.com>

Hi Vladimir,

thanks for the review and sorry for the late reply (we had a public
holiday in Germany:).


On Wed, May 13, 2015 at 8:39 PM, Vladimir Kozlov
<vladimir.kozlov at oracle.com> wrote:
> Is this because you can have negative values?
> I see that at the bottom of calls which generate bits u_field() method is
> used. Why not mask it there?
>

u_field() generates immediates in the range (hi_bit - lo_bit + 1) but
it can be used to generate not only 5-bit immediates but also bigger
or smaller ones (e.g. tbr() calls u_field() to generate a 10-bit
immediate. The assertion in u_field() checks that the given value can
be encoded in the requested range of bits but we do not want to
explicitly mask the value to the corresponding bit range as this could
hide other problems.

The other problem is that we can have negative values as you have
correctly noticed.

I think this is more a kind of a conceptual problem. The JLS states
that "only the five lowest-order bits of the right-hand operand are
used as the shift distance" in a shift operation [1]. The same holds
true for the specifications of the shift bytecodes in the JVMS [2].
But for constant shift amounts we do not handle this in C2 (i.e. in
the ideal graph) but instead we relay on the corresponding CPU
instruction doing "the right thing". On x86 this works because the
whole 8-bit immediates are encoded right into the instruction and
interpreted as required by the JLS.

Another way to solve this would be to do the masking right in the
ideal graph as we've previously done in the SAP JVM:

Node *LShiftINode::Ideal(PhaseGVN *phase, bool can_reshape) {
  const Type *t  = phase->type( in(2) );
  if( t == Type::TOP ) return NULL;       // Right input is dead
  const TypeInt *t2 = t->isa_int();
  if( !t2 || !t2->is_con() ) return NULL; // Right input is a constant

  // SAPJVM: mask constant shift count already in ideal graph processing
  const int in2_con = t2->get_con();
  const int con     = in2_con & ( BitsPerJavaInteger - 1 );   //
masked shift count

  if ( con == 0 )  return NULL; // let Identity() handle 0 shift count

  if( in2_con != con ) {
    set_req( 2, phase->intcon(con) ); // replace shift count with masked value
  }

Damned! I just wanted to ask you what's your opinion about this
solution but while writing all this and doing some software
archaeology I just discovered that this problem has already been
discussed [3] and solved some time ago! Change "7029017: Additional
architecture support for c2 compiler" introduced  the "Support (for)
masking of shift counts when the processor architecture mandates it".
This is exactly what's needed on PowerPC!

So I'd like to change my fix as follows:

http://cr.openjdk.java.net/~simonis/webrevs/2015/8080190.v3/

I think that using "Matcher::need_masked_shift_count = true" will make
a lot of the masking for shift instructions in the ppc.ad file
obsolete, but I'd like to keep these cleanups for a separate change.

Regards,
Volker

[1] https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.19
[2] https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.ishl
[3] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-March/thread.html#4944

> There are other instructions which can have the same problem (slwi). You
> would have to guarantee all of those do the masking. That is why I am asking
> why not mask it at the final code methods, like u_field()?
>
> Thanks,
> Vladimir
>
>
> On 5/13/15 9:29 AM, Volker Simonis wrote:
>>
>> Hi,
>>
>> could you please review the following, ppc64-only fix which solves a
>> problem with the integer-rotate instructions in C2:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8080190
>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8080190.v2/
>>
>> The problem was that we initially took the "rotate left/right by 8-bit
>> immediate" instructions from x86_64. But on x86_64 the rotate
>> instructions for 32-bit integers do in fact really take 8-bit
>> immediates (seems like the Intel guys had to many spare bits when they
>> designed their instruction set :) On the other hand, the rotate
>> instructions on Power only use 5 bit to encode the rotation distance.
>>
>> We do check for this limit, but only in the debug build so you'll see
>> an assertion there, but in the product build we will silently emit a
>> wrong instruction which can lead to anything starting from a crash up
>> to an incorrect computation.
>>
>> I think the simplest solution for this problem is to mask the
>> rotation distance with 0x1f  (which is equivalent to taking the
>> distance modulo 32) in the corresponding instructions.
>>
>> This change should also be backported to 8 as fast as possible. Notice
>> that this a day-zero bug in our ppc64 port because in our internal SAP
>> JVM we already mask the shift amounts in the ideal graph but for some
>> unknown reasons these shared changes haven?t been contributed along
>> with our port.
>>
>> Thank you and best regards,
>> Volker
>>
>

From vladimir.kozlov at oracle.com  Mon May 18 16:42:56 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Mon, 18 May 2015 09:42:56 -0700
Subject: RFR(S): 8080190: PPC64: Fix wrong rotate instructions in the
	.ad file
In-Reply-To: <CA+3eh11MPV+tHXrtWN9teya7b=4O-iitU3pvuA3Yxa9s43SL4A@mail.gmail.com>
References: <CA+3eh13agOYGrDRY8-ENrKzh1Xe+tFRsz-0_uKbOpbJwVzM_SA@mail.gmail.com>	<55539A49.4010906@oracle.com>
	<CA+3eh11MPV+tHXrtWN9teya7b=4O-iitU3pvuA3Yxa9s43SL4A@mail.gmail.com>
Message-ID: <555A1690.40704@oracle.com>

You need to change the comment in ppc.ad.
Otherwise looks good. Thank you for doing archeological research - I 
forgot about that change.

Thanks,
Vladimir

On 5/18/15 9:05 AM, Volker Simonis wrote:
> Hi Vladimir,
>
> thanks for the review and sorry for the late reply (we had a public
> holiday in Germany:).
>
>
> On Wed, May 13, 2015 at 8:39 PM, Vladimir Kozlov
> <vladimir.kozlov at oracle.com> wrote:
>> Is this because you can have negative values?
>> I see that at the bottom of calls which generate bits u_field() method is
>> used. Why not mask it there?
>>
>
> u_field() generates immediates in the range (hi_bit - lo_bit + 1) but
> it can be used to generate not only 5-bit immediates but also bigger
> or smaller ones (e.g. tbr() calls u_field() to generate a 10-bit
> immediate. The assertion in u_field() checks that the given value can
> be encoded in the requested range of bits but we do not want to
> explicitly mask the value to the corresponding bit range as this could
> hide other problems.
>
> The other problem is that we can have negative values as you have
> correctly noticed.
>
> I think this is more a kind of a conceptual problem. The JLS states
> that "only the five lowest-order bits of the right-hand operand are
> used as the shift distance" in a shift operation [1]. The same holds
> true for the specifications of the shift bytecodes in the JVMS [2].
> But for constant shift amounts we do not handle this in C2 (i.e. in
> the ideal graph) but instead we relay on the corresponding CPU
> instruction doing "the right thing". On x86 this works because the
> whole 8-bit immediates are encoded right into the instruction and
> interpreted as required by the JLS.
>
> Another way to solve this would be to do the masking right in the
> ideal graph as we've previously done in the SAP JVM:
>
> Node *LShiftINode::Ideal(PhaseGVN *phase, bool can_reshape) {
>    const Type *t  = phase->type( in(2) );
>    if( t == Type::TOP ) return NULL;       // Right input is dead
>    const TypeInt *t2 = t->isa_int();
>    if( !t2 || !t2->is_con() ) return NULL; // Right input is a constant
>
>    // SAPJVM: mask constant shift count already in ideal graph processing
>    const int in2_con = t2->get_con();
>    const int con     = in2_con & ( BitsPerJavaInteger - 1 );   //
> masked shift count
>
>    if ( con == 0 )  return NULL; // let Identity() handle 0 shift count
>
>    if( in2_con != con ) {
>      set_req( 2, phase->intcon(con) ); // replace shift count with masked value
>    }
>
> Damned! I just wanted to ask you what's your opinion about this
> solution but while writing all this and doing some software
> archaeology I just discovered that this problem has already been
> discussed [3] and solved some time ago! Change "7029017: Additional
> architecture support for c2 compiler" introduced  the "Support (for)
> masking of shift counts when the processor architecture mandates it".
> This is exactly what's needed on PowerPC!
>
> So I'd like to change my fix as follows:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8080190.v3/
>
> I think that using "Matcher::need_masked_shift_count = true" will make
> a lot of the masking for shift instructions in the ppc.ad file
> obsolete, but I'd like to keep these cleanups for a separate change.
>
> Regards,
> Volker
>
> [1] https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.19
> [2] https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.ishl
> [3] http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-March/thread.html#4944
>
>> There are other instructions which can have the same problem (slwi). You
>> would have to guarantee all of those do the masking. That is why I am asking
>> why not mask it at the final code methods, like u_field()?
>>
>> Thanks,
>> Vladimir
>>
>>
>> On 5/13/15 9:29 AM, Volker Simonis wrote:
>>>
>>> Hi,
>>>
>>> could you please review the following, ppc64-only fix which solves a
>>> problem with the integer-rotate instructions in C2:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8080190
>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8080190.v2/
>>>
>>> The problem was that we initially took the "rotate left/right by 8-bit
>>> immediate" instructions from x86_64. But on x86_64 the rotate
>>> instructions for 32-bit integers do in fact really take 8-bit
>>> immediates (seems like the Intel guys had to many spare bits when they
>>> designed their instruction set :) On the other hand, the rotate
>>> instructions on Power only use 5 bit to encode the rotation distance.
>>>
>>> We do check for this limit, but only in the debug build so you'll see
>>> an assertion there, but in the product build we will silently emit a
>>> wrong instruction which can lead to anything starting from a crash up
>>> to an incorrect computation.
>>>
>>> I think the simplest solution for this problem is to mask the
>>> rotation distance with 0x1f  (which is equivalent to taking the
>>> distance modulo 32) in the corresponding instructions.
>>>
>>> This change should also be backported to 8 as fast as possible. Notice
>>> that this a day-zero bug in our ppc64 port because in our internal SAP
>>> JVM we already mask the shift amounts in the ideal graph but for some
>>> unknown reasons these shared changes haven?t been contributed along
>>> with our port.
>>>
>>> Thank you and best regards,
>>> Volker
>>>
>>

From volker.simonis at gmail.com  Mon May 18 16:53:14 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 18 May 2015 18:53:14 +0200
Subject: RFR(S): 8080190: PPC64: Fix wrong rotate instructions in the .ad
	file
In-Reply-To: <555A1690.40704@oracle.com>
References: <CA+3eh13agOYGrDRY8-ENrKzh1Xe+tFRsz-0_uKbOpbJwVzM_SA@mail.gmail.com>
	<55539A49.4010906@oracle.com>
	<CA+3eh11MPV+tHXrtWN9teya7b=4O-iitU3pvuA3Yxa9s43SL4A@mail.gmail.com>
	<555A1690.40704@oracle.com>
Message-ID: <CA+3eh10pG0ObNgt=4hYKwL_-=hCRXF4Lxvr=s+RVXhzuyzJOYA@mail.gmail.com>

Thanks for the review!
I'll update the comment accordingly.

Regards,
Volker


On Mon, May 18, 2015 at 6:42 PM, Vladimir Kozlov
<vladimir.kozlov at oracle.com> wrote:
> You need to change the comment in ppc.ad.
> Otherwise looks good. Thank you for doing archeological research - I forgot
> about that change.
>
> Thanks,
> Vladimir
>
>
> On 5/18/15 9:05 AM, Volker Simonis wrote:
>>
>> Hi Vladimir,
>>
>> thanks for the review and sorry for the late reply (we had a public
>> holiday in Germany:).
>>
>>
>> On Wed, May 13, 2015 at 8:39 PM, Vladimir Kozlov
>> <vladimir.kozlov at oracle.com> wrote:
>>>
>>> Is this because you can have negative values?
>>> I see that at the bottom of calls which generate bits u_field() method is
>>> used. Why not mask it there?
>>>
>>
>> u_field() generates immediates in the range (hi_bit - lo_bit + 1) but
>> it can be used to generate not only 5-bit immediates but also bigger
>> or smaller ones (e.g. tbr() calls u_field() to generate a 10-bit
>> immediate. The assertion in u_field() checks that the given value can
>> be encoded in the requested range of bits but we do not want to
>> explicitly mask the value to the corresponding bit range as this could
>> hide other problems.
>>
>> The other problem is that we can have negative values as you have
>> correctly noticed.
>>
>> I think this is more a kind of a conceptual problem. The JLS states
>> that "only the five lowest-order bits of the right-hand operand are
>> used as the shift distance" in a shift operation [1]. The same holds
>> true for the specifications of the shift bytecodes in the JVMS [2].
>> But for constant shift amounts we do not handle this in C2 (i.e. in
>> the ideal graph) but instead we relay on the corresponding CPU
>> instruction doing "the right thing". On x86 this works because the
>> whole 8-bit immediates are encoded right into the instruction and
>> interpreted as required by the JLS.
>>
>> Another way to solve this would be to do the masking right in the
>> ideal graph as we've previously done in the SAP JVM:
>>
>> Node *LShiftINode::Ideal(PhaseGVN *phase, bool can_reshape) {
>>    const Type *t  = phase->type( in(2) );
>>    if( t == Type::TOP ) return NULL;       // Right input is dead
>>    const TypeInt *t2 = t->isa_int();
>>    if( !t2 || !t2->is_con() ) return NULL; // Right input is a constant
>>
>>    // SAPJVM: mask constant shift count already in ideal graph processing
>>    const int in2_con = t2->get_con();
>>    const int con     = in2_con & ( BitsPerJavaInteger - 1 );   //
>> masked shift count
>>
>>    if ( con == 0 )  return NULL; // let Identity() handle 0 shift count
>>
>>    if( in2_con != con ) {
>>      set_req( 2, phase->intcon(con) ); // replace shift count with masked
>> value
>>    }
>>
>> Damned! I just wanted to ask you what's your opinion about this
>> solution but while writing all this and doing some software
>> archaeology I just discovered that this problem has already been
>> discussed [3] and solved some time ago! Change "7029017: Additional
>> architecture support for c2 compiler" introduced  the "Support (for)
>> masking of shift counts when the processor architecture mandates it".
>> This is exactly what's needed on PowerPC!
>>
>> So I'd like to change my fix as follows:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8080190.v3/
>>
>> I think that using "Matcher::need_masked_shift_count = true" will make
>> a lot of the masking for shift instructions in the ppc.ad file
>> obsolete, but I'd like to keep these cleanups for a separate change.
>>
>> Regards,
>> Volker
>>
>> [1]
>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.19
>> [2]
>> https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html#jvms-6.5.ishl
>> [3]
>> http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/2011-March/thread.html#4944
>>
>>> There are other instructions which can have the same problem (slwi). You
>>> would have to guarantee all of those do the masking. That is why I am
>>> asking
>>> why not mask it at the final code methods, like u_field()?
>>>
>>> Thanks,
>>> Vladimir
>>>
>>>
>>> On 5/13/15 9:29 AM, Volker Simonis wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> could you please review the following, ppc64-only fix which solves a
>>>> problem with the integer-rotate instructions in C2:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8080190
>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8080190.v2/
>>>>
>>>> The problem was that we initially took the "rotate left/right by 8-bit
>>>> immediate" instructions from x86_64. But on x86_64 the rotate
>>>> instructions for 32-bit integers do in fact really take 8-bit
>>>> immediates (seems like the Intel guys had to many spare bits when they
>>>> designed their instruction set :) On the other hand, the rotate
>>>> instructions on Power only use 5 bit to encode the rotation distance.
>>>>
>>>> We do check for this limit, but only in the debug build so you'll see
>>>> an assertion there, but in the product build we will silently emit a
>>>> wrong instruction which can lead to anything starting from a crash up
>>>> to an incorrect computation.
>>>>
>>>> I think the simplest solution for this problem is to mask the
>>>> rotation distance with 0x1f  (which is equivalent to taking the
>>>> distance modulo 32) in the corresponding instructions.
>>>>
>>>> This change should also be backported to 8 as fast as possible. Notice
>>>> that this a day-zero bug in our ppc64 port because in our internal SAP
>>>> JVM we already mask the shift amounts in the ideal graph but for some
>>>> unknown reasons these shared changes haven?t been contributed along
>>>> with our port.
>>>>
>>>> Thank you and best regards,
>>>> Volker
>>>>
>>>
>

From volker.simonis at gmail.com  Tue May 19 16:41:45 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 19 May 2015 18:41:45 +0200
Subject: RFR(S): 8080684: PPC64: Fix little-endian build after "8077838:
	Recent developments for ppc"
Message-ID: <CA+3eh11hZ1TK_zsLyJMfKmiHhtG9HYfLAJLJ0cTW+PTOEi1Mkg@mail.gmail.com>

Hi,

can I please get a review for the following fix of the ppc64le build.

@Sasha, Tiago: I would be also especially interested if somebody with
a little-endian ppc64 system can check if the fix really works there
as I have currently no access to such a system.

https://bugs.openjdk.java.net/browse/JDK-8080684
http://cr.openjdk.java.net/~simonis/webrevs/2015/8080684/

Following the details:

On big-endian ppc64 we need so called 'function descriptors' instead
of simple pointers in order to call functions. That's why the
Assembler class on ppc64 offers an 'emit_fd()' method which can be
used to create such a function descriptor.

On little-endian ppc64 the ABI was changed (i.e. ABI_ELFv2) and
function descriptors have been removed. That's why the before
mentioned 'emit_fd()' is being excluded from the build with the help
of preprocessor macros if the HotSpot is being build in a little
endian environment:

#if !defined(ABI_ELFv2)
inline address emit_fd(...)
#endif

The drawback of this approach is that every call site which uses
'emit_fd()' has to conditionally handle the case where 'emit_fd()'
isn't present as well. This was exactly the problem with change
"8077838: Recent developments for ppc" which introduced an
unconditional call to 'emit_fd()' in 'VM_Version::config_dscr() which
lead to a build failure on little endian.

A better approach would be to make 'emit_fd()' available on both,
little- and big-endian platforms and handle the difference internally,
within the function itself. On little-endian, the function will just
return the current PC without emitting any code at all while the
big-endian variant emits the required function descriptor.

Thank you and best regards,
Volker

From vladimir.kozlov at oracle.com  Tue May 19 21:55:40 2015
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Tue, 19 May 2015 14:55:40 -0700
Subject: RFR(S): 8080684: PPC64: Fix little-endian build after "8077838:
	Recent developments for ppc"
In-Reply-To: <CA+3eh11hZ1TK_zsLyJMfKmiHhtG9HYfLAJLJ0cTW+PTOEi1Mkg@mail.gmail.com>
References: <CA+3eh11hZ1TK_zsLyJMfKmiHhtG9HYfLAJLJ0cTW+PTOEi1Mkg@mail.gmail.com>
Message-ID: <555BB15C.4020305@oracle.com>

Looks good to me.

Thanks,
Vladimir

On 5/19/15 9:41 AM, Volker Simonis wrote:
> Hi,
>
> can I please get a review for the following fix of the ppc64le build.
>
> @Sasha, Tiago: I would be also especially interested if somebody with
> a little-endian ppc64 system can check if the fix really works there
> as I have currently no access to such a system.
>
> https://bugs.openjdk.java.net/browse/JDK-8080684
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8080684/
>
> Following the details:
>
> On big-endian ppc64 we need so called 'function descriptors' instead
> of simple pointers in order to call functions. That's why the
> Assembler class on ppc64 offers an 'emit_fd()' method which can be
> used to create such a function descriptor.
>
> On little-endian ppc64 the ABI was changed (i.e. ABI_ELFv2) and
> function descriptors have been removed. That's why the before
> mentioned 'emit_fd()' is being excluded from the build with the help
> of preprocessor macros if the HotSpot is being build in a little
> endian environment:
>
> #if !defined(ABI_ELFv2)
> inline address emit_fd(...)
> #endif
>
> The drawback of this approach is that every call site which uses
> 'emit_fd()' has to conditionally handle the case where 'emit_fd()'
> isn't present as well. This was exactly the problem with change
> "8077838: Recent developments for ppc" which introduced an
> unconditional call to 'emit_fd()' in 'VM_Version::config_dscr() which
> lead to a build failure on little endian.
>
> A better approach would be to make 'emit_fd()' available on both,
> little- and big-endian platforms and handle the difference internally,
> within the function itself. On little-endian, the function will just
> return the current PC without emitting any code at all while the
> big-endian variant emits the required function descriptor.
>
> Thank you and best regards,
> Volker
>

From asmundak at google.com  Wed May 20 01:25:58 2015
From: asmundak at google.com (Alexander Smundak)
Date: Tue, 19 May 2015 18:25:58 -0700
Subject: RFR(S): 8080684: PPC64: Fix little-endian build after "8077838:
	Recent developments for ppc"
In-Reply-To: <CA+3eh11hZ1TK_zsLyJMfKmiHhtG9HYfLAJLJ0cTW+PTOEi1Mkg@mail.gmail.com>
References: <CA+3eh11hZ1TK_zsLyJMfKmiHhtG9HYfLAJLJ0cTW+PTOEi1Mkg@mail.gmail.com>
Message-ID: <CAHQ51u5wSCP_PJO1Xhoo0Ko+BR_XC0vdVWjshBpnZ6KqGPEZRg@mail.gmail.com>

It fails to compile because the code still references FileDescriptor,
even if ABI_ELFv2 is defined.
The revised patch which succeeds is here:
http://cr.openjdk.java.net/~asmundak/8080684/hotspot/webrev
(it's for jdk8u-dev branch)
but IMHO the proposed change isn't semantically right --
if a method is called emit_fd, it should create a FileDescriptor.
I am not sure that rationale behind this patch is right -- a
compile-time error  is usually easy to fix and verify that the semantics
is correct while fixing it, whereas runtime error usually requires
more effort.


On Tue, May 19, 2015 at 9:41 AM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> Hi,
>
> can I please get a review for the following fix of the ppc64le build.
>
> @Sasha, Tiago: I would be also especially interested if somebody with
> a little-endian ppc64 system can check if the fix really works there
> as I have currently no access to such a system.
>
> https://bugs.openjdk.java.net/browse/JDK-8080684
> http://cr.openjdk.java.net/~simonis/webrevs/2015/8080684/
>
> Following the details:
>
> On big-endian ppc64 we need so called 'function descriptors' instead
> of simple pointers in order to call functions. That's why the
> Assembler class on ppc64 offers an 'emit_fd()' method which can be
> used to create such a function descriptor.
>
> On little-endian ppc64 the ABI was changed (i.e. ABI_ELFv2) and
> function descriptors have been removed. That's why the before
> mentioned 'emit_fd()' is being excluded from the build with the help
> of preprocessor macros if the HotSpot is being build in a little
> endian environment:
>
> #if !defined(ABI_ELFv2)
> inline address emit_fd(...)
> #endif
>
> The drawback of this approach is that every call site which uses
> 'emit_fd()' has to conditionally handle the case where 'emit_fd()'
> isn't present as well. This was exactly the problem with change
> "8077838: Recent developments for ppc" which introduced an
> unconditional call to 'emit_fd()' in 'VM_Version::config_dscr() which
> lead to a build failure on little endian.
>
> A better approach would be to make 'emit_fd()' available on both,
> little- and big-endian platforms and handle the difference internally,
> within the function itself. On little-endian, the function will just
> return the current PC without emitting any code at all while the
> big-endian variant emits the required function descriptor.
>
> Thank you and best regards,
> Volker

From volker.simonis at gmail.com  Wed May 20 08:45:17 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 20 May 2015 10:45:17 +0200
Subject: hotspot: problem with bitwise rotation on PowerLE
In-Reply-To: <CA+3eh11FuXooZWc6N5TAUUGLtmBMoAnRWP2=1ZXLBMMq3K1j4A@mail.gmail.com>
References: <OFF86722F2.508E098C-ON86257E3F.006CCF46-86257E3F.006E0494@us.ibm.com>
	<CAHQ51u4V=hzOv39oN7nPOwNfzBg6Sx_2_WMhgT3zPx+U=5Zo2g@mail.gmail.com>
	<CA+3eh10ObFX-_A0ajkFC5P5yefbcTCFRMs_O=u=3HfZaazozNA@mail.gmail.com>
	<CA+3eh13V0gjpasBYHgaTWcZ76WRDFaT9j-6y8C6Hp8WXHMt+aA@mail.gmail.com>
	<CAHQ51u4ZbnngDfN1KGPPSu7wZh_61CpadqDAq_-Z-rmVE1BopQ@mail.gmail.com>
	<OF51E2D972.253ABEBB-ON86257E43.007497B3-86257E43.0074F9F3@us.ibm.com>
	<CAHQ51u44VxV27vz-9NR8ztkGG8ToJ1z+ubdyqP4=nL4ujq9RPQ@mail.gmail.com>
	<CA+3eh11FuXooZWc6N5TAUUGLtmBMoAnRWP2=1ZXLBMMq3K1j4A@mail.gmail.com>
Message-ID: <CA+3eh11aNh0KdwE5o6K_dHZEHchgtcPUg5S+fHPV+G5=6O0ivA@mail.gmail.com>

I just wanted to let you know that this issue has now been fixed in
jdk9 and jdk8u.

Currently the change for 9 is in the jdk9/hs-comp/hotspot team
repository but it should propagate to jdk9/dev/hotspot soon (in a week
or two).

The fix for 8u is currently in jdk8u/hs-dev/hotspot but should
propagate to jdk8u/dev in time for the upcoming 8u60 release.

You can watch the status of the fix at:

https://bugs.openjdk.java.net/browse/JDK-8080190 for jdk9 and:
https://bugs.openjdk.java.net/browse/JDK-8080749 for the 8u downport.

Thanks for reporting this.
Volker


On Wed, May 13, 2015 at 11:36 AM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> Thanks, but I've already written a minimal test case myself.
>
> I just asked for including the initial test by Jan because it also
> exercises some other interesting parts of the optimizer and may thus
> be a valuable test case in itself.
>
> Regards,
> Volker
>
>
> On Wed, May 13, 2015 at 12:34 AM, Alexander Smundak <asmundak at google.com> wrote:
>> I have somewhat more isolated test (just calling
>> rotateRigth/rotateLeft methods from my previous e-mail with constant
>> distance argument that reveals the problem. Please let me know if you
>> are interested.
>>
>> On Tue, May 12, 2015 at 2:17 PM, Jan S Rellermeyer
>> <rellermeyer at us.ibm.com> wrote:
>>> I have also been able test the patch in our setup and it works. Thanks for
>>> figuring this out.
>>>
>>> Do you happen to know when the next 8 update release is scheduled that would
>>> contain the fix?
>>>
>>> Regarding coverage by the IBM OCA and the ability to contribute the hash
>>> code for regression testing, I am checking this right now with the people
>>> who passed the code on to me.
>>>
>>> --Jan.
>>>
>>> Alexander Smundak ---05/12/2015 03:59:48 PM---I can confirm that the patch
>>> works. I tried to write the test that covers both 'rotlI_reg_immi8' and
>>>
>>> From: Alexander Smundak <asmundak at google.com>
>>> To: Volker Simonis <volker.simonis at gmail.com>
>>> Cc: Jan S Rellermeyer/Austin/IBM at IBMUS, "ppc-aix-port-dev at openjdk.java.net"
>>> <ppc-aix-port-dev at openjdk.java.net>
>>> Date: 05/12/2015 03:59 PM
>>> Subject: Re: hotspot: problem with bitwise rotation on PowerLE
>>>
>>> ________________________________
>>>
>>>
>>>
>>> I can confirm that the patch works. I tried to write the test that covers
>>> both
>>> 'rotlI_reg_immi8' and ' rotrI_reg_immi8' patterns but I didn't manage
>>> to match the latter,
>>> somehow all of the following methods inline to ROTLWI:
>>>
>>>  static int rotateRight1(int i, int distance) { return (i >>>
>>> distance) | (i << -distance); }
>>>  static int rotateRight2(int i, int distance) { return (i <<
>>> -distance) | (i >>> distance); }
>>>
>>> These two inline to
>>>    rotlwi Rx, Ry, (32-distance)
>>>
>>>  static int rotateLeft1(int i, int distance) { return (i << distance)
>>> | (i >>> -distance); }
>>>  static int rotateLeft2(int i, int distance) { return (i >>>
>>> -distance) | (i << distance); }
>>> And these to inline to
>>>    rotlwi Rx, Ry, distance
>>>
>>> How can such a bug escape the hotspot test? I don't have access to
>>> JCK, but isn't it supposed to cover this?
>>>
>>> On Tue, May 12, 2015 at 11:31 AM, Volker Simonis
>>> <volker.simonis at gmail.com> wrote:
>>>> Hi,
>>>>
>>>> I think I've finally understood and fixed this issue.
>>>>
>>>> The problem was that we initially took the "rotate left/right by 8-bit
>>>> immediate" instructions from x86_64. But on x86_64 the rotate
>>>> instructions for 32-bit integers do in fact really take 8-bit
>>>> immediates (seems like the Intel guys had to many spare bits when they
>>>> designed their instruction set :) On the other hand, the rotate
>>>> instructions on Power only use 5 bit to encode the rotation distance.
>>>>
>>>> We do check for this limit, but only in the debug build. That's why
>>>> you saw the assertion in the fastdebug build.
>>>>
>>>> I think the right solution for this problem is to simply mask the
>>>> rotation distance with 0x1f  (which is equivalent to taking the
>>>> distance modulo 32).
>>>>
>>>> Can you please verify that the proposed fix also works for you on LE?
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8080190
>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8080190/
>>>>
>>>> If yes I can send it out for review and push it to our jdk9 and jdk8u
>>>> repositories.
>>>>
>>>> @Jan: have you signed the Oracle Contributor Agreement or are you
>>>> covered by the company-wide IBM OCA? I'd like to take your test as a
>>>> regresstion test into the OpenJDK HotSpot repository, but this is only
>>>> possible if you're a Contributor[2].
>>>>
>>>> Thank you and best regards,
>>>> Volker
>>>>
>>>> PS: the issue didn't appear in our internal SAP JVM version because we
>>>> already mask the inputs of the corresponding shift nodes in the ideal
>>>> graph but for some unknown reasons this shared changes haven?t been
>>>> contributed along with our ppc port so far.
>>>>
>>>> [1] http://www.oracle.com/technetwork/community/oca-486395.html
>>>> [2] http://openjdk.java.net/bylaws#contributor
>>>>
>>>>
>>>> On Tue, May 12, 2015 at 2:38 PM, Volker Simonis
>>>> <volker.simonis at gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> this problem is not LE-related. I could reproduce it on BE as well. I
>>>>> also don't think that the fix proposed by Jan is completely right. I
>>>>> think it only helps because it leads to another instruction being
>>>>> matched. The problem is that the URshift has a negative input which
>>>>> should not be. It should have been converted to it's positive
>>>>> equivalent modulo 32 (as described in the  JLS 15.19 -
>>>>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.19).
>>>>>
>>>>> Strange enough, in our internal version, the error doesn't occur so I
>>>>> should actually easy find the difference. Unfortunately, I didn't saw
>>>>> it until now :(
>>>>> I'll keep you posted once I found out more...
>>>>>
>>>>> Regards,
>>>>> Volker
>>>>>
>>>>> On Tue, May 12, 2015 at 6:06 AM, Alexander Smundak <asmundak at google.com>
>>>>> wrote:
>>>>>> Looking into this. Sorry for the late response, we were moved into a
>>>>>> different office over the weekend.
>>>>>>
>>>>>> On Fri, May 8, 2015 at 1:01 PM, Jan S Rellermeyer
>>>>>> <rellermeyer at us.ibm.com> wrote:
>>>>>>> I am helping people in IBM who have encountered a hotspot bug that
>>>>>>> surfaces
>>>>>>> when using bitwise rotations (such as through Integer.rotateRight). I
>>>>>>> have
>>>>>>> attached a small test program that illustrates the problem. When
>>>>>>> running
>>>>>>> this on Power LE (I don't think that anybody tried on BE, though) the
>>>>>>> results of the hash function are incorrect.
>>>>>>>
>>>>>>> The bug goes away when disabling inlining. After digging through the
>>>>>>> generated code I found out that it contained some suspicious fnmadd
>>>>>>> instructions where you would rather expect some kind of left rotate. I
>>>>>>> could
>>>>>>> track down that the bug was caused by the immediate value for the right
>>>>>>> shift constant of what should be a rlwinm node to be negative and
>>>>>>> thereby
>>>>>>> bleeding into the opcode (which unfortunately still created a valid
>>>>>>> Power
>>>>>>> instruction, namely the fnmadd). Running with a fastdebug build causes
>>>>>>> an
>>>>>>> assertion to fail.
>>>>>>>
>>>>>>> The attached patch does fix the problem and so does an alternative
>>>>>>> patch
>>>>>>> that replaces the URshift with a UShift but I am not entirely sure if
>>>>>>> this
>>>>>>> really fixes the root cause or rather just prevents the rotlI
>>>>>>> instruction
>>>>>>> from being matched by the ReduceInst.
>>>>>>>
>>>>>>> --Jan.
>>>>>>>
>>>>>>>
>>>>>>> Dr. Jan S. Rellermeyer
>>>>>>> IBM Research
>>>>>>> RSM - Austin Research Lab
>>>>>>> rellermeyer_at_us.ibm.com
>>>>>>> The University of Texas at Austin
>>>>>>> Adjunct Assistant Professor
>>>>>>> jrellerm_at_cs.utexas.edu
>>>>>>>
>>>>>>> (See attached file: hash.java)(See attached file: rotl.patch)
>>>
>>>
>>>

From tony.reix at atos.net  Wed May 20 10:37:10 2015
From: tony.reix at atos.net (Tony Reix)
Date: Wed, 20 May 2015 10:37:10 +0000
Subject: hotspot: problem with bitwise rotation on PowerLE
In-Reply-To: <CA+3eh11aNh0KdwE5o6K_dHZEHchgtcPUg5S+fHPV+G5=6O0ivA@mail.gmail.com>
References: <OFF86722F2.508E098C-ON86257E3F.006CCF46-86257E3F.006E0494@us.ibm.com>
	<CAHQ51u4V=hzOv39oN7nPOwNfzBg6Sx_2_WMhgT3zPx+U=5Zo2g@mail.gmail.com>
	<CA+3eh10ObFX-_A0ajkFC5P5yefbcTCFRMs_O=u=3HfZaazozNA@mail.gmail.com>
	<CA+3eh13V0gjpasBYHgaTWcZ76WRDFaT9j-6y8C6Hp8WXHMt+aA@mail.gmail.com>
	<CAHQ51u4ZbnngDfN1KGPPSu7wZh_61CpadqDAq_-Z-rmVE1BopQ@mail.gmail.com>
	<OF51E2D972.253ABEBB-ON86257E43.007497B3-86257E43.0074F9F3@us.ibm.com>
	<CAHQ51u44VxV27vz-9NR8ztkGG8ToJ1z+ubdyqP4=nL4ujq9RPQ@mail.gmail.com>
	<CA+3eh11FuXooZWc6N5TAUUGLtmBMoAnRWP2=1ZXLBMMq3K1j4A@mail.gmail.com>,
	<CA+3eh11aNh0KdwE5o6K_dHZEHchgtcPUg5S+fHPV+G5=6O0ivA@mail.gmail.com>
Message-ID: <5EFAF879C767CF40BD00D800C20AE80E7CF83300@BUMSG3WM.fr.ad.bull.net>

What about jdk7 ?


Cordialement,

Tony Reix

Bull - ATOS
IBM Coop Architect & Technical Leader
Office : +33 (0) 4 76 29 72 67
1 rue de Provence - 38432 ?chirolles - France
www.atos.net

________________________________________
De : ppc-aix-port-dev [ppc-aix-port-dev-bounces at openjdk.java.net] de la part de Volker Simonis [volker.simonis at gmail.com]
Envoy? : mercredi 20 mai 2015 10:45
? : Alexander Smundak
Cc : ppc-aix-port-dev at openjdk.java.net
Objet : Re: hotspot: problem with bitwise rotation on PowerLE

I just wanted to let you know that this issue has now been fixed in
jdk9 and jdk8u.

Currently the change for 9 is in the jdk9/hs-comp/hotspot team
repository but it should propagate to jdk9/dev/hotspot soon (in a week
or two).

The fix for 8u is currently in jdk8u/hs-dev/hotspot but should
propagate to jdk8u/dev in time for the upcoming 8u60 release.

You can watch the status of the fix at:

https://bugs.openjdk.java.net/browse/JDK-8080190 for jdk9 and:
https://bugs.openjdk.java.net/browse/JDK-8080749 for the 8u downport.

Thanks for reporting this.
Volker


On Wed, May 13, 2015 at 11:36 AM, Volker Simonis
<volker.simonis at gmail.com> wrote:
> Thanks, but I've already written a minimal test case myself.
>
> I just asked for including the initial test by Jan because it also
> exercises some other interesting parts of the optimizer and may thus
> be a valuable test case in itself.
>
> Regards,
> Volker
>
>
> On Wed, May 13, 2015 at 12:34 AM, Alexander Smundak <asmundak at google.com> wrote:
>> I have somewhat more isolated test (just calling
>> rotateRigth/rotateLeft methods from my previous e-mail with constant
>> distance argument that reveals the problem. Please let me know if you
>> are interested.
>>
>> On Tue, May 12, 2015 at 2:17 PM, Jan S Rellermeyer
>> <rellermeyer at us.ibm.com> wrote:
>>> I have also been able test the patch in our setup and it works. Thanks for
>>> figuring this out.
>>>
>>> Do you happen to know when the next 8 update release is scheduled that would
>>> contain the fix?
>>>
>>> Regarding coverage by the IBM OCA and the ability to contribute the hash
>>> code for regression testing, I am checking this right now with the people
>>> who passed the code on to me.
>>>
>>> --Jan.
>>>
>>> Alexander Smundak ---05/12/2015 03:59:48 PM---I can confirm that the patch
>>> works. I tried to write the test that covers both 'rotlI_reg_immi8' and
>>>
>>> From: Alexander Smundak <asmundak at google.com>
>>> To: Volker Simonis <volker.simonis at gmail.com>
>>> Cc: Jan S Rellermeyer/Austin/IBM at IBMUS, "ppc-aix-port-dev at openjdk.java.net"
>>> <ppc-aix-port-dev at openjdk.java.net>
>>> Date: 05/12/2015 03:59 PM
>>> Subject: Re: hotspot: problem with bitwise rotation on PowerLE
>>>
>>> ________________________________
>>>
>>>
>>>
>>> I can confirm that the patch works. I tried to write the test that covers
>>> both
>>> 'rotlI_reg_immi8' and ' rotrI_reg_immi8' patterns but I didn't manage
>>> to match the latter,
>>> somehow all of the following methods inline to ROTLWI:
>>>
>>>  static int rotateRight1(int i, int distance) { return (i >>>
>>> distance) | (i << -distance); }
>>>  static int rotateRight2(int i, int distance) { return (i <<
>>> -distance) | (i >>> distance); }
>>>
>>> These two inline to
>>>    rotlwi Rx, Ry, (32-distance)
>>>
>>>  static int rotateLeft1(int i, int distance) { return (i << distance)
>>> | (i >>> -distance); }
>>>  static int rotateLeft2(int i, int distance) { return (i >>>
>>> -distance) | (i << distance); }
>>> And these to inline to
>>>    rotlwi Rx, Ry, distance
>>>
>>> How can such a bug escape the hotspot test? I don't have access to
>>> JCK, but isn't it supposed to cover this?
>>>
>>> On Tue, May 12, 2015 at 11:31 AM, Volker Simonis
>>> <volker.simonis at gmail.com> wrote:
>>>> Hi,
>>>>
>>>> I think I've finally understood and fixed this issue.
>>>>
>>>> The problem was that we initially took the "rotate left/right by 8-bit
>>>> immediate" instructions from x86_64. But on x86_64 the rotate
>>>> instructions for 32-bit integers do in fact really take 8-bit
>>>> immediates (seems like the Intel guys had to many spare bits when they
>>>> designed their instruction set :) On the other hand, the rotate
>>>> instructions on Power only use 5 bit to encode the rotation distance.
>>>>
>>>> We do check for this limit, but only in the debug build. That's why
>>>> you saw the assertion in the fastdebug build.
>>>>
>>>> I think the right solution for this problem is to simply mask the
>>>> rotation distance with 0x1f  (which is equivalent to taking the
>>>> distance modulo 32).
>>>>
>>>> Can you please verify that the proposed fix also works for you on LE?
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8080190
>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8080190/
>>>>
>>>> If yes I can send it out for review and push it to our jdk9 and jdk8u
>>>> repositories.
>>>>
>>>> @Jan: have you signed the Oracle Contributor Agreement or are you
>>>> covered by the company-wide IBM OCA? I'd like to take your test as a
>>>> regresstion test into the OpenJDK HotSpot repository, but this is only
>>>> possible if you're a Contributor[2].
>>>>
>>>> Thank you and best regards,
>>>> Volker
>>>>
>>>> PS: the issue didn't appear in our internal SAP JVM version because we
>>>> already mask the inputs of the corresponding shift nodes in the ideal
>>>> graph but for some unknown reasons this shared changes haven?t been
>>>> contributed along with our ppc port so far.
>>>>
>>>> [1] http://www.oracle.com/technetwork/community/oca-486395.html
>>>> [2] http://openjdk.java.net/bylaws#contributor
>>>>
>>>>
>>>> On Tue, May 12, 2015 at 2:38 PM, Volker Simonis
>>>> <volker.simonis at gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> this problem is not LE-related. I could reproduce it on BE as well. I
>>>>> also don't think that the fix proposed by Jan is completely right. I
>>>>> think it only helps because it leads to another instruction being
>>>>> matched. The problem is that the URshift has a negative input which
>>>>> should not be. It should have been converted to it's positive
>>>>> equivalent modulo 32 (as described in the  JLS 15.19 -
>>>>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.19).
>>>>>
>>>>> Strange enough, in our internal version, the error doesn't occur so I
>>>>> should actually easy find the difference. Unfortunately, I didn't saw
>>>>> it until now :(
>>>>> I'll keep you posted once I found out more...
>>>>>
>>>>> Regards,
>>>>> Volker
>>>>>
>>>>> On Tue, May 12, 2015 at 6:06 AM, Alexander Smundak <asmundak at google.com>
>>>>> wrote:
>>>>>> Looking into this. Sorry for the late response, we were moved into a
>>>>>> different office over the weekend.
>>>>>>
>>>>>> On Fri, May 8, 2015 at 1:01 PM, Jan S Rellermeyer
>>>>>> <rellermeyer at us.ibm.com> wrote:
>>>>>>> I am helping people in IBM who have encountered a hotspot bug that
>>>>>>> surfaces
>>>>>>> when using bitwise rotations (such as through Integer.rotateRight). I
>>>>>>> have
>>>>>>> attached a small test program that illustrates the problem. When
>>>>>>> running
>>>>>>> this on Power LE (I don't think that anybody tried on BE, though) the
>>>>>>> results of the hash function are incorrect.
>>>>>>>
>>>>>>> The bug goes away when disabling inlining. After digging through the
>>>>>>> generated code I found out that it contained some suspicious fnmadd
>>>>>>> instructions where you would rather expect some kind of left rotate. I
>>>>>>> could
>>>>>>> track down that the bug was caused by the immediate value for the right
>>>>>>> shift constant of what should be a rlwinm node to be negative and
>>>>>>> thereby
>>>>>>> bleeding into the opcode (which unfortunately still created a valid
>>>>>>> Power
>>>>>>> instruction, namely the fnmadd). Running with a fastdebug build causes
>>>>>>> an
>>>>>>> assertion to fail.
>>>>>>>
>>>>>>> The attached patch does fix the problem and so does an alternative
>>>>>>> patch
>>>>>>> that replaces the URshift with a UShift but I am not entirely sure if
>>>>>>> this
>>>>>>> really fixes the root cause or rather just prevents the rotlI
>>>>>>> instruction
>>>>>>> from being matched by the ReduceInst.
>>>>>>>
>>>>>>> --Jan.
>>>>>>>
>>>>>>>
>>>>>>> Dr. Jan S. Rellermeyer
>>>>>>> IBM Research
>>>>>>> RSM - Austin Research Lab
>>>>>>> rellermeyer_at_us.ibm.com
>>>>>>> The University of Texas at Austin
>>>>>>> Adjunct Assistant Professor
>>>>>>> jrellerm_at_cs.utexas.edu
>>>>>>>
>>>>>>> (See attached file: hash.java)(See attached file: rotl.patch)
>>>
>>>
>>>

From volker.simonis at gmail.com  Wed May 20 12:40:53 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 20 May 2015 14:40:53 +0200
Subject: hotspot: problem with bitwise rotation on PowerLE
In-Reply-To: <5EFAF879C767CF40BD00D800C20AE80E7CF83300@BUMSG3WM.fr.ad.bull.net>
References: <OFF86722F2.508E098C-ON86257E3F.006CCF46-86257E3F.006E0494@us.ibm.com>
	<CAHQ51u4V=hzOv39oN7nPOwNfzBg6Sx_2_WMhgT3zPx+U=5Zo2g@mail.gmail.com>
	<CA+3eh10ObFX-_A0ajkFC5P5yefbcTCFRMs_O=u=3HfZaazozNA@mail.gmail.com>
	<CA+3eh13V0gjpasBYHgaTWcZ76WRDFaT9j-6y8C6Hp8WXHMt+aA@mail.gmail.com>
	<CAHQ51u4ZbnngDfN1KGPPSu7wZh_61CpadqDAq_-Z-rmVE1BopQ@mail.gmail.com>
	<OF51E2D972.253ABEBB-ON86257E43.007497B3-86257E43.0074F9F3@us.ibm.com>
	<CAHQ51u44VxV27vz-9NR8ztkGG8ToJ1z+ubdyqP4=nL4ujq9RPQ@mail.gmail.com>
	<CA+3eh11FuXooZWc6N5TAUUGLtmBMoAnRWP2=1ZXLBMMq3K1j4A@mail.gmail.com>
	<CA+3eh11aNh0KdwE5o6K_dHZEHchgtcPUg5S+fHPV+G5=6O0ivA@mail.gmail.com>
	<5EFAF879C767CF40BD00D800C20AE80E7CF83300@BUMSG3WM.fr.ad.bull.net>
Message-ID: <CA+3eh13rzg3GpYjTN=LFh5SQoROLeVrNo4-yzWCn+9mwjnCwGQ@mail.gmail.com>

I'm just testing the change.
I'll let you know once I've pushed it.

Regards,
Volker


On Wed, May 20, 2015 at 12:37 PM, Tony Reix <tony.reix at atos.net> wrote:
> What about jdk7 ?
>
>
> Cordialement,
>
> Tony Reix
>
> Bull - ATOS
> IBM Coop Architect & Technical Leader
> Office : +33 (0) 4 76 29 72 67
> 1 rue de Provence - 38432 ?chirolles - France
> www.atos.net
>
> ________________________________________
> De : ppc-aix-port-dev [ppc-aix-port-dev-bounces at openjdk.java.net] de la part de Volker Simonis [volker.simonis at gmail.com]
> Envoy? : mercredi 20 mai 2015 10:45
> ? : Alexander Smundak
> Cc : ppc-aix-port-dev at openjdk.java.net
> Objet : Re: hotspot: problem with bitwise rotation on PowerLE
>
> I just wanted to let you know that this issue has now been fixed in
> jdk9 and jdk8u.
>
> Currently the change for 9 is in the jdk9/hs-comp/hotspot team
> repository but it should propagate to jdk9/dev/hotspot soon (in a week
> or two).
>
> The fix for 8u is currently in jdk8u/hs-dev/hotspot but should
> propagate to jdk8u/dev in time for the upcoming 8u60 release.
>
> You can watch the status of the fix at:
>
> https://bugs.openjdk.java.net/browse/JDK-8080190 for jdk9 and:
> https://bugs.openjdk.java.net/browse/JDK-8080749 for the 8u downport.
>
> Thanks for reporting this.
> Volker
>
>
> On Wed, May 13, 2015 at 11:36 AM, Volker Simonis
> <volker.simonis at gmail.com> wrote:
>> Thanks, but I've already written a minimal test case myself.
>>
>> I just asked for including the initial test by Jan because it also
>> exercises some other interesting parts of the optimizer and may thus
>> be a valuable test case in itself.
>>
>> Regards,
>> Volker
>>
>>
>> On Wed, May 13, 2015 at 12:34 AM, Alexander Smundak <asmundak at google.com> wrote:
>>> I have somewhat more isolated test (just calling
>>> rotateRigth/rotateLeft methods from my previous e-mail with constant
>>> distance argument that reveals the problem. Please let me know if you
>>> are interested.
>>>
>>> On Tue, May 12, 2015 at 2:17 PM, Jan S Rellermeyer
>>> <rellermeyer at us.ibm.com> wrote:
>>>> I have also been able test the patch in our setup and it works. Thanks for
>>>> figuring this out.
>>>>
>>>> Do you happen to know when the next 8 update release is scheduled that would
>>>> contain the fix?
>>>>
>>>> Regarding coverage by the IBM OCA and the ability to contribute the hash
>>>> code for regression testing, I am checking this right now with the people
>>>> who passed the code on to me.
>>>>
>>>> --Jan.
>>>>
>>>> Alexander Smundak ---05/12/2015 03:59:48 PM---I can confirm that the patch
>>>> works. I tried to write the test that covers both 'rotlI_reg_immi8' and
>>>>
>>>> From: Alexander Smundak <asmundak at google.com>
>>>> To: Volker Simonis <volker.simonis at gmail.com>
>>>> Cc: Jan S Rellermeyer/Austin/IBM at IBMUS, "ppc-aix-port-dev at openjdk.java.net"
>>>> <ppc-aix-port-dev at openjdk.java.net>
>>>> Date: 05/12/2015 03:59 PM
>>>> Subject: Re: hotspot: problem with bitwise rotation on PowerLE
>>>>
>>>> ________________________________
>>>>
>>>>
>>>>
>>>> I can confirm that the patch works. I tried to write the test that covers
>>>> both
>>>> 'rotlI_reg_immi8' and ' rotrI_reg_immi8' patterns but I didn't manage
>>>> to match the latter,
>>>> somehow all of the following methods inline to ROTLWI:
>>>>
>>>>  static int rotateRight1(int i, int distance) { return (i >>>
>>>> distance) | (i << -distance); }
>>>>  static int rotateRight2(int i, int distance) { return (i <<
>>>> -distance) | (i >>> distance); }
>>>>
>>>> These two inline to
>>>>    rotlwi Rx, Ry, (32-distance)
>>>>
>>>>  static int rotateLeft1(int i, int distance) { return (i << distance)
>>>> | (i >>> -distance); }
>>>>  static int rotateLeft2(int i, int distance) { return (i >>>
>>>> -distance) | (i << distance); }
>>>> And these to inline to
>>>>    rotlwi Rx, Ry, distance
>>>>
>>>> How can such a bug escape the hotspot test? I don't have access to
>>>> JCK, but isn't it supposed to cover this?
>>>>
>>>> On Tue, May 12, 2015 at 11:31 AM, Volker Simonis
>>>> <volker.simonis at gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> I think I've finally understood and fixed this issue.
>>>>>
>>>>> The problem was that we initially took the "rotate left/right by 8-bit
>>>>> immediate" instructions from x86_64. But on x86_64 the rotate
>>>>> instructions for 32-bit integers do in fact really take 8-bit
>>>>> immediates (seems like the Intel guys had to many spare bits when they
>>>>> designed their instruction set :) On the other hand, the rotate
>>>>> instructions on Power only use 5 bit to encode the rotation distance.
>>>>>
>>>>> We do check for this limit, but only in the debug build. That's why
>>>>> you saw the assertion in the fastdebug build.
>>>>>
>>>>> I think the right solution for this problem is to simply mask the
>>>>> rotation distance with 0x1f  (which is equivalent to taking the
>>>>> distance modulo 32).
>>>>>
>>>>> Can you please verify that the proposed fix also works for you on LE?
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8080190
>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8080190/
>>>>>
>>>>> If yes I can send it out for review and push it to our jdk9 and jdk8u
>>>>> repositories.
>>>>>
>>>>> @Jan: have you signed the Oracle Contributor Agreement or are you
>>>>> covered by the company-wide IBM OCA? I'd like to take your test as a
>>>>> regresstion test into the OpenJDK HotSpot repository, but this is only
>>>>> possible if you're a Contributor[2].
>>>>>
>>>>> Thank you and best regards,
>>>>> Volker
>>>>>
>>>>> PS: the issue didn't appear in our internal SAP JVM version because we
>>>>> already mask the inputs of the corresponding shift nodes in the ideal
>>>>> graph but for some unknown reasons this shared changes haven?t been
>>>>> contributed along with our ppc port so far.
>>>>>
>>>>> [1] http://www.oracle.com/technetwork/community/oca-486395.html
>>>>> [2] http://openjdk.java.net/bylaws#contributor
>>>>>
>>>>>
>>>>> On Tue, May 12, 2015 at 2:38 PM, Volker Simonis
>>>>> <volker.simonis at gmail.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> this problem is not LE-related. I could reproduce it on BE as well. I
>>>>>> also don't think that the fix proposed by Jan is completely right. I
>>>>>> think it only helps because it leads to another instruction being
>>>>>> matched. The problem is that the URshift has a negative input which
>>>>>> should not be. It should have been converted to it's positive
>>>>>> equivalent modulo 32 (as described in the  JLS 15.19 -
>>>>>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.19).
>>>>>>
>>>>>> Strange enough, in our internal version, the error doesn't occur so I
>>>>>> should actually easy find the difference. Unfortunately, I didn't saw
>>>>>> it until now :(
>>>>>> I'll keep you posted once I found out more...
>>>>>>
>>>>>> Regards,
>>>>>> Volker
>>>>>>
>>>>>> On Tue, May 12, 2015 at 6:06 AM, Alexander Smundak <asmundak at google.com>
>>>>>> wrote:
>>>>>>> Looking into this. Sorry for the late response, we were moved into a
>>>>>>> different office over the weekend.
>>>>>>>
>>>>>>> On Fri, May 8, 2015 at 1:01 PM, Jan S Rellermeyer
>>>>>>> <rellermeyer at us.ibm.com> wrote:
>>>>>>>> I am helping people in IBM who have encountered a hotspot bug that
>>>>>>>> surfaces
>>>>>>>> when using bitwise rotations (such as through Integer.rotateRight). I
>>>>>>>> have
>>>>>>>> attached a small test program that illustrates the problem. When
>>>>>>>> running
>>>>>>>> this on Power LE (I don't think that anybody tried on BE, though) the
>>>>>>>> results of the hash function are incorrect.
>>>>>>>>
>>>>>>>> The bug goes away when disabling inlining. After digging through the
>>>>>>>> generated code I found out that it contained some suspicious fnmadd
>>>>>>>> instructions where you would rather expect some kind of left rotate. I
>>>>>>>> could
>>>>>>>> track down that the bug was caused by the immediate value for the right
>>>>>>>> shift constant of what should be a rlwinm node to be negative and
>>>>>>>> thereby
>>>>>>>> bleeding into the opcode (which unfortunately still created a valid
>>>>>>>> Power
>>>>>>>> instruction, namely the fnmadd). Running with a fastdebug build causes
>>>>>>>> an
>>>>>>>> assertion to fail.
>>>>>>>>
>>>>>>>> The attached patch does fix the problem and so does an alternative
>>>>>>>> patch
>>>>>>>> that replaces the URshift with a UShift but I am not entirely sure if
>>>>>>>> this
>>>>>>>> really fixes the root cause or rather just prevents the rotlI
>>>>>>>> instruction
>>>>>>>> from being matched by the ReduceInst.
>>>>>>>>
>>>>>>>> --Jan.
>>>>>>>>
>>>>>>>>
>>>>>>>> Dr. Jan S. Rellermeyer
>>>>>>>> IBM Research
>>>>>>>> RSM - Austin Research Lab
>>>>>>>> rellermeyer_at_us.ibm.com
>>>>>>>> The University of Texas at Austin
>>>>>>>> Adjunct Assistant Professor
>>>>>>>> jrellerm_at_cs.utexas.edu
>>>>>>>>
>>>>>>>> (See attached file: hash.java)(See attached file: rotl.patch)
>>>>
>>>>
>>>>

From volker.simonis at gmail.com  Wed May 20 13:41:23 2015
From: volker.simonis at gmail.com (volker.simonis at gmail.com)
Date: Wed, 20 May 2015 13:41:23 +0000
Subject: hg: ppc-aix-port/jdk7u/hotspot: 8080190: PPC64: Fix wrong rotate
	instructions in the .ad file
Message-ID: <201505201341.t4KDfN2k001807@aojmv0008.oracle.com>

Changeset: c1394d3bdb6a
Author:    simonis
Date:      2015-05-19 11:06 +0200
URL:       http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c1394d3bdb6a

8080190: PPC64: Fix wrong rotate instructions in the .ad file
Reviewed-by: kvn

! src/cpu/ppc/vm/ppc.ad
+ test/compiler/codegen/IntRotateWithImmediate.java


From volker.simonis at gmail.com  Wed May 20 13:50:07 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 20 May 2015 15:50:07 +0200
Subject: hotspot: problem with bitwise rotation on PowerLE
In-Reply-To: <5EFAF879C767CF40BD00D800C20AE80E7CF83300@BUMSG3WM.fr.ad.bull.net>
References: <OFF86722F2.508E098C-ON86257E3F.006CCF46-86257E3F.006E0494@us.ibm.com>
	<CAHQ51u4V=hzOv39oN7nPOwNfzBg6Sx_2_WMhgT3zPx+U=5Zo2g@mail.gmail.com>
	<CA+3eh10ObFX-_A0ajkFC5P5yefbcTCFRMs_O=u=3HfZaazozNA@mail.gmail.com>
	<CA+3eh13V0gjpasBYHgaTWcZ76WRDFaT9j-6y8C6Hp8WXHMt+aA@mail.gmail.com>
	<CAHQ51u4ZbnngDfN1KGPPSu7wZh_61CpadqDAq_-Z-rmVE1BopQ@mail.gmail.com>
	<OF51E2D972.253ABEBB-ON86257E43.007497B3-86257E43.0074F9F3@us.ibm.com>
	<CAHQ51u44VxV27vz-9NR8ztkGG8ToJ1z+ubdyqP4=nL4ujq9RPQ@mail.gmail.com>
	<CA+3eh11FuXooZWc6N5TAUUGLtmBMoAnRWP2=1ZXLBMMq3K1j4A@mail.gmail.com>
	<CA+3eh11aNh0KdwE5o6K_dHZEHchgtcPUg5S+fHPV+G5=6O0ivA@mail.gmail.com>
	<5EFAF879C767CF40BD00D800C20AE80E7CF83300@BUMSG3WM.fr.ad.bull.net>
Message-ID: <CA+3eh12XiO-kXeQwmhRmTge2Ma=oRDyyqMfydFAtikGc+0V2NA@mail.gmail.com>

I have now also fixed this issue in our ppc-aix-port/jdk7u repository

http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c1394d3bdb6a

Please consider pulling this change into your local repositories if
you are building on Linux/ppc64 or AIX because it will not be
integrated into the main jdk7u/hotspot repository (simply because the
main jdk7u/hotspot does not yet contain the ppc64 port).

Regards,
Volker


On Wed, May 20, 2015 at 12:37 PM, Tony Reix <tony.reix at atos.net> wrote:
> What about jdk7 ?
>
>
> Cordialement,
>
> Tony Reix
>
> Bull - ATOS
> IBM Coop Architect & Technical Leader
> Office : +33 (0) 4 76 29 72 67
> 1 rue de Provence - 38432 ?chirolles - France
> www.atos.net
>
> ________________________________________
> De : ppc-aix-port-dev [ppc-aix-port-dev-bounces at openjdk.java.net] de la part de Volker Simonis [volker.simonis at gmail.com]
> Envoy? : mercredi 20 mai 2015 10:45
> ? : Alexander Smundak
> Cc : ppc-aix-port-dev at openjdk.java.net
> Objet : Re: hotspot: problem with bitwise rotation on PowerLE
>
> I just wanted to let you know that this issue has now been fixed in
> jdk9 and jdk8u.
>
> Currently the change for 9 is in the jdk9/hs-comp/hotspot team
> repository but it should propagate to jdk9/dev/hotspot soon (in a week
> or two).
>
> The fix for 8u is currently in jdk8u/hs-dev/hotspot but should
> propagate to jdk8u/dev in time for the upcoming 8u60 release.
>
> You can watch the status of the fix at:
>
> https://bugs.openjdk.java.net/browse/JDK-8080190 for jdk9 and:
> https://bugs.openjdk.java.net/browse/JDK-8080749 for the 8u downport.
>
> Thanks for reporting this.
> Volker
>
>
> On Wed, May 13, 2015 at 11:36 AM, Volker Simonis
> <volker.simonis at gmail.com> wrote:
>> Thanks, but I've already written a minimal test case myself.
>>
>> I just asked for including the initial test by Jan because it also
>> exercises some other interesting parts of the optimizer and may thus
>> be a valuable test case in itself.
>>
>> Regards,
>> Volker
>>
>>
>> On Wed, May 13, 2015 at 12:34 AM, Alexander Smundak <asmundak at google.com> wrote:
>>> I have somewhat more isolated test (just calling
>>> rotateRigth/rotateLeft methods from my previous e-mail with constant
>>> distance argument that reveals the problem. Please let me know if you
>>> are interested.
>>>
>>> On Tue, May 12, 2015 at 2:17 PM, Jan S Rellermeyer
>>> <rellermeyer at us.ibm.com> wrote:
>>>> I have also been able test the patch in our setup and it works. Thanks for
>>>> figuring this out.
>>>>
>>>> Do you happen to know when the next 8 update release is scheduled that would
>>>> contain the fix?
>>>>
>>>> Regarding coverage by the IBM OCA and the ability to contribute the hash
>>>> code for regression testing, I am checking this right now with the people
>>>> who passed the code on to me.
>>>>
>>>> --Jan.
>>>>
>>>> Alexander Smundak ---05/12/2015 03:59:48 PM---I can confirm that the patch
>>>> works. I tried to write the test that covers both 'rotlI_reg_immi8' and
>>>>
>>>> From: Alexander Smundak <asmundak at google.com>
>>>> To: Volker Simonis <volker.simonis at gmail.com>
>>>> Cc: Jan S Rellermeyer/Austin/IBM at IBMUS, "ppc-aix-port-dev at openjdk.java.net"
>>>> <ppc-aix-port-dev at openjdk.java.net>
>>>> Date: 05/12/2015 03:59 PM
>>>> Subject: Re: hotspot: problem with bitwise rotation on PowerLE
>>>>
>>>> ________________________________
>>>>
>>>>
>>>>
>>>> I can confirm that the patch works. I tried to write the test that covers
>>>> both
>>>> 'rotlI_reg_immi8' and ' rotrI_reg_immi8' patterns but I didn't manage
>>>> to match the latter,
>>>> somehow all of the following methods inline to ROTLWI:
>>>>
>>>>  static int rotateRight1(int i, int distance) { return (i >>>
>>>> distance) | (i << -distance); }
>>>>  static int rotateRight2(int i, int distance) { return (i <<
>>>> -distance) | (i >>> distance); }
>>>>
>>>> These two inline to
>>>>    rotlwi Rx, Ry, (32-distance)
>>>>
>>>>  static int rotateLeft1(int i, int distance) { return (i << distance)
>>>> | (i >>> -distance); }
>>>>  static int rotateLeft2(int i, int distance) { return (i >>>
>>>> -distance) | (i << distance); }
>>>> And these to inline to
>>>>    rotlwi Rx, Ry, distance
>>>>
>>>> How can such a bug escape the hotspot test? I don't have access to
>>>> JCK, but isn't it supposed to cover this?
>>>>
>>>> On Tue, May 12, 2015 at 11:31 AM, Volker Simonis
>>>> <volker.simonis at gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> I think I've finally understood and fixed this issue.
>>>>>
>>>>> The problem was that we initially took the "rotate left/right by 8-bit
>>>>> immediate" instructions from x86_64. But on x86_64 the rotate
>>>>> instructions for 32-bit integers do in fact really take 8-bit
>>>>> immediates (seems like the Intel guys had to many spare bits when they
>>>>> designed their instruction set :) On the other hand, the rotate
>>>>> instructions on Power only use 5 bit to encode the rotation distance.
>>>>>
>>>>> We do check for this limit, but only in the debug build. That's why
>>>>> you saw the assertion in the fastdebug build.
>>>>>
>>>>> I think the right solution for this problem is to simply mask the
>>>>> rotation distance with 0x1f  (which is equivalent to taking the
>>>>> distance modulo 32).
>>>>>
>>>>> Can you please verify that the proposed fix also works for you on LE?
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8080190
>>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8080190/
>>>>>
>>>>> If yes I can send it out for review and push it to our jdk9 and jdk8u
>>>>> repositories.
>>>>>
>>>>> @Jan: have you signed the Oracle Contributor Agreement or are you
>>>>> covered by the company-wide IBM OCA? I'd like to take your test as a
>>>>> regresstion test into the OpenJDK HotSpot repository, but this is only
>>>>> possible if you're a Contributor[2].
>>>>>
>>>>> Thank you and best regards,
>>>>> Volker
>>>>>
>>>>> PS: the issue didn't appear in our internal SAP JVM version because we
>>>>> already mask the inputs of the corresponding shift nodes in the ideal
>>>>> graph but for some unknown reasons this shared changes haven?t been
>>>>> contributed along with our ppc port so far.
>>>>>
>>>>> [1] http://www.oracle.com/technetwork/community/oca-486395.html
>>>>> [2] http://openjdk.java.net/bylaws#contributor
>>>>>
>>>>>
>>>>> On Tue, May 12, 2015 at 2:38 PM, Volker Simonis
>>>>> <volker.simonis at gmail.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> this problem is not LE-related. I could reproduce it on BE as well. I
>>>>>> also don't think that the fix proposed by Jan is completely right. I
>>>>>> think it only helps because it leads to another instruction being
>>>>>> matched. The problem is that the URshift has a negative input which
>>>>>> should not be. It should have been converted to it's positive
>>>>>> equivalent modulo 32 (as described in the  JLS 15.19 -
>>>>>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.19).
>>>>>>
>>>>>> Strange enough, in our internal version, the error doesn't occur so I
>>>>>> should actually easy find the difference. Unfortunately, I didn't saw
>>>>>> it until now :(
>>>>>> I'll keep you posted once I found out more...
>>>>>>
>>>>>> Regards,
>>>>>> Volker
>>>>>>
>>>>>> On Tue, May 12, 2015 at 6:06 AM, Alexander Smundak <asmundak at google.com>
>>>>>> wrote:
>>>>>>> Looking into this. Sorry for the late response, we were moved into a
>>>>>>> different office over the weekend.
>>>>>>>
>>>>>>> On Fri, May 8, 2015 at 1:01 PM, Jan S Rellermeyer
>>>>>>> <rellermeyer at us.ibm.com> wrote:
>>>>>>>> I am helping people in IBM who have encountered a hotspot bug that
>>>>>>>> surfaces
>>>>>>>> when using bitwise rotations (such as through Integer.rotateRight). I
>>>>>>>> have
>>>>>>>> attached a small test program that illustrates the problem. When
>>>>>>>> running
>>>>>>>> this on Power LE (I don't think that anybody tried on BE, though) the
>>>>>>>> results of the hash function are incorrect.
>>>>>>>>
>>>>>>>> The bug goes away when disabling inlining. After digging through the
>>>>>>>> generated code I found out that it contained some suspicious fnmadd
>>>>>>>> instructions where you would rather expect some kind of left rotate. I
>>>>>>>> could
>>>>>>>> track down that the bug was caused by the immediate value for the right
>>>>>>>> shift constant of what should be a rlwinm node to be negative and
>>>>>>>> thereby
>>>>>>>> bleeding into the opcode (which unfortunately still created a valid
>>>>>>>> Power
>>>>>>>> instruction, namely the fnmadd). Running with a fastdebug build causes
>>>>>>>> an
>>>>>>>> assertion to fail.
>>>>>>>>
>>>>>>>> The attached patch does fix the problem and so does an alternative
>>>>>>>> patch
>>>>>>>> that replaces the URshift with a UShift but I am not entirely sure if
>>>>>>>> this
>>>>>>>> really fixes the root cause or rather just prevents the rotlI
>>>>>>>> instruction
>>>>>>>> from being matched by the ReduceInst.
>>>>>>>>
>>>>>>>> --Jan.
>>>>>>>>
>>>>>>>>
>>>>>>>> Dr. Jan S. Rellermeyer
>>>>>>>> IBM Research
>>>>>>>> RSM - Austin Research Lab
>>>>>>>> rellermeyer_at_us.ibm.com
>>>>>>>> The University of Texas at Austin
>>>>>>>> Adjunct Assistant Professor
>>>>>>>> jrellerm_at_cs.utexas.edu
>>>>>>>>
>>>>>>>> (See attached file: hash.java)(See attached file: rotl.patch)
>>>>
>>>>
>>>>

From gnu.andrew at redhat.com  Wed May 20 14:56:44 2015
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 20 May 2015 10:56:44 -0400 (EDT)
Subject: hotspot: problem with bitwise rotation on PowerLE
In-Reply-To: <CA+3eh12XiO-kXeQwmhRmTge2Ma=oRDyyqMfydFAtikGc+0V2NA@mail.gmail.com>
References: <OFF86722F2.508E098C-ON86257E3F.006CCF46-86257E3F.006E0494@us.ibm.com>
	<CAHQ51u4ZbnngDfN1KGPPSu7wZh_61CpadqDAq_-Z-rmVE1BopQ@mail.gmail.com>
	<OF51E2D972.253ABEBB-ON86257E43.007497B3-86257E43.0074F9F3@us.ibm.com>
	<CAHQ51u44VxV27vz-9NR8ztkGG8ToJ1z+ubdyqP4=nL4ujq9RPQ@mail.gmail.com>
	<CA+3eh11FuXooZWc6N5TAUUGLtmBMoAnRWP2=1ZXLBMMq3K1j4A@mail.gmail.com>
	<CA+3eh11aNh0KdwE5o6K_dHZEHchgtcPUg5S+fHPV+G5=6O0ivA@mail.gmail.com>
	<5EFAF879C767CF40BD00D800C20AE80E7CF83300@BUMSG3WM.fr.ad.bull.net>
	<CA+3eh12XiO-kXeQwmhRmTge2Ma=oRDyyqMfydFAtikGc+0V2NA@mail.gmail.com>
Message-ID: <1755118965.2748464.1432133804042.JavaMail.zimbra@redhat.com>

----- Original Message -----
> I have now also fixed this issue in our ppc-aix-port/jdk7u repository
> 
> http://hg.openjdk.java.net/ppc-aix-port/jdk7u/hotspot/rev/c1394d3bdb6a
> 
> Please consider pulling this change into your local repositories if
> you are building on Linux/ppc64 or AIX because it will not be
> integrated into the main jdk7u/hotspot repository (simply because the
> main jdk7u/hotspot does not yet contain the ppc64 port).
> 

I plan to do a sync with the ppc-aix-port/jdk7u tree before our next
releases of IcedTea (2.6.0 ASAP and 2.5.6 for the July CPU).

> Regards,
> Volker
> 
> 
> On Wed, May 20, 2015 at 12:37 PM, Tony Reix <tony.reix at atos.net> wrote:
> > What about jdk7 ?
> >
> >
> > Cordialement,
> >
> > Tony Reix
> >
> > Bull - ATOS
> > IBM Coop Architect & Technical Leader
> > Office : +33 (0) 4 76 29 72 67
> > 1 rue de Provence - 38432 ?chirolles - France
> > www.atos.net
> >
> > ________________________________________
> > De : ppc-aix-port-dev [ppc-aix-port-dev-bounces at openjdk.java.net] de la
> > part de Volker Simonis [volker.simonis at gmail.com]
> > Envoy? : mercredi 20 mai 2015 10:45
> > ? : Alexander Smundak
> > Cc : ppc-aix-port-dev at openjdk.java.net
> > Objet : Re: hotspot: problem with bitwise rotation on PowerLE
> >
> > I just wanted to let you know that this issue has now been fixed in
> > jdk9 and jdk8u.
> >
> > Currently the change for 9 is in the jdk9/hs-comp/hotspot team
> > repository but it should propagate to jdk9/dev/hotspot soon (in a week
> > or two).
> >
> > The fix for 8u is currently in jdk8u/hs-dev/hotspot but should
> > propagate to jdk8u/dev in time for the upcoming 8u60 release.
> >
> > You can watch the status of the fix at:
> >
> > https://bugs.openjdk.java.net/browse/JDK-8080190 for jdk9 and:
> > https://bugs.openjdk.java.net/browse/JDK-8080749 for the 8u downport.
> >
> > Thanks for reporting this.
> > Volker
> >
> >
> > On Wed, May 13, 2015 at 11:36 AM, Volker Simonis
> > <volker.simonis at gmail.com> wrote:
> >> Thanks, but I've already written a minimal test case myself.
> >>
> >> I just asked for including the initial test by Jan because it also
> >> exercises some other interesting parts of the optimizer and may thus
> >> be a valuable test case in itself.
> >>
> >> Regards,
> >> Volker
> >>
> >>
> >> On Wed, May 13, 2015 at 12:34 AM, Alexander Smundak <asmundak at google.com>
> >> wrote:
> >>> I have somewhat more isolated test (just calling
> >>> rotateRigth/rotateLeft methods from my previous e-mail with constant
> >>> distance argument that reveals the problem. Please let me know if you
> >>> are interested.
> >>>
> >>> On Tue, May 12, 2015 at 2:17 PM, Jan S Rellermeyer
> >>> <rellermeyer at us.ibm.com> wrote:
> >>>> I have also been able test the patch in our setup and it works. Thanks
> >>>> for
> >>>> figuring this out.
> >>>>
> >>>> Do you happen to know when the next 8 update release is scheduled that
> >>>> would
> >>>> contain the fix?
> >>>>
> >>>> Regarding coverage by the IBM OCA and the ability to contribute the hash
> >>>> code for regression testing, I am checking this right now with the
> >>>> people
> >>>> who passed the code on to me.
> >>>>
> >>>> --Jan.
> >>>>
> >>>> Alexander Smundak ---05/12/2015 03:59:48 PM---I can confirm that the
> >>>> patch
> >>>> works. I tried to write the test that covers both 'rotlI_reg_immi8' and
> >>>>
> >>>> From: Alexander Smundak <asmundak at google.com>
> >>>> To: Volker Simonis <volker.simonis at gmail.com>
> >>>> Cc: Jan S Rellermeyer/Austin/IBM at IBMUS,
> >>>> "ppc-aix-port-dev at openjdk.java.net"
> >>>> <ppc-aix-port-dev at openjdk.java.net>
> >>>> Date: 05/12/2015 03:59 PM
> >>>> Subject: Re: hotspot: problem with bitwise rotation on PowerLE
> >>>>
> >>>> ________________________________
> >>>>
> >>>>
> >>>>
> >>>> I can confirm that the patch works. I tried to write the test that
> >>>> covers
> >>>> both
> >>>> 'rotlI_reg_immi8' and ' rotrI_reg_immi8' patterns but I didn't manage
> >>>> to match the latter,
> >>>> somehow all of the following methods inline to ROTLWI:
> >>>>
> >>>>  static int rotateRight1(int i, int distance) { return (i >>>
> >>>> distance) | (i << -distance); }
> >>>>  static int rotateRight2(int i, int distance) { return (i <<
> >>>> -distance) | (i >>> distance); }
> >>>>
> >>>> These two inline to
> >>>>    rotlwi Rx, Ry, (32-distance)
> >>>>
> >>>>  static int rotateLeft1(int i, int distance) { return (i << distance)
> >>>> | (i >>> -distance); }
> >>>>  static int rotateLeft2(int i, int distance) { return (i >>>
> >>>> -distance) | (i << distance); }
> >>>> And these to inline to
> >>>>    rotlwi Rx, Ry, distance
> >>>>
> >>>> How can such a bug escape the hotspot test? I don't have access to
> >>>> JCK, but isn't it supposed to cover this?
> >>>>
> >>>> On Tue, May 12, 2015 at 11:31 AM, Volker Simonis
> >>>> <volker.simonis at gmail.com> wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I think I've finally understood and fixed this issue.
> >>>>>
> >>>>> The problem was that we initially took the "rotate left/right by 8-bit
> >>>>> immediate" instructions from x86_64. But on x86_64 the rotate
> >>>>> instructions for 32-bit integers do in fact really take 8-bit
> >>>>> immediates (seems like the Intel guys had to many spare bits when they
> >>>>> designed their instruction set :) On the other hand, the rotate
> >>>>> instructions on Power only use 5 bit to encode the rotation distance.
> >>>>>
> >>>>> We do check for this limit, but only in the debug build. That's why
> >>>>> you saw the assertion in the fastdebug build.
> >>>>>
> >>>>> I think the right solution for this problem is to simply mask the
> >>>>> rotation distance with 0x1f  (which is equivalent to taking the
> >>>>> distance modulo 32).
> >>>>>
> >>>>> Can you please verify that the proposed fix also works for you on LE?
> >>>>>
> >>>>> https://bugs.openjdk.java.net/browse/JDK-8080190
> >>>>> http://cr.openjdk.java.net/~simonis/webrevs/2015/8080190/
> >>>>>
> >>>>> If yes I can send it out for review and push it to our jdk9 and jdk8u
> >>>>> repositories.
> >>>>>
> >>>>> @Jan: have you signed the Oracle Contributor Agreement or are you
> >>>>> covered by the company-wide IBM OCA? I'd like to take your test as a
> >>>>> regresstion test into the OpenJDK HotSpot repository, but this is only
> >>>>> possible if you're a Contributor[2].
> >>>>>
> >>>>> Thank you and best regards,
> >>>>> Volker
> >>>>>
> >>>>> PS: the issue didn't appear in our internal SAP JVM version because we
> >>>>> already mask the inputs of the corresponding shift nodes in the ideal
> >>>>> graph but for some unknown reasons this shared changes haven?t been
> >>>>> contributed along with our ppc port so far.
> >>>>>
> >>>>> [1] http://www.oracle.com/technetwork/community/oca-486395.html
> >>>>> [2] http://openjdk.java.net/bylaws#contributor
> >>>>>
> >>>>>
> >>>>> On Tue, May 12, 2015 at 2:38 PM, Volker Simonis
> >>>>> <volker.simonis at gmail.com> wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> this problem is not LE-related. I could reproduce it on BE as well. I
> >>>>>> also don't think that the fix proposed by Jan is completely right. I
> >>>>>> think it only helps because it leads to another instruction being
> >>>>>> matched. The problem is that the URshift has a negative input which
> >>>>>> should not be. It should have been converted to it's positive
> >>>>>> equivalent modulo 32 (as described in the  JLS 15.19 -
> >>>>>> https://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.19).
> >>>>>>
> >>>>>> Strange enough, in our internal version, the error doesn't occur so I
> >>>>>> should actually easy find the difference. Unfortunately, I didn't saw
> >>>>>> it until now :(
> >>>>>> I'll keep you posted once I found out more...
> >>>>>>
> >>>>>> Regards,
> >>>>>> Volker
> >>>>>>
> >>>>>> On Tue, May 12, 2015 at 6:06 AM, Alexander Smundak
> >>>>>> <asmundak at google.com>
> >>>>>> wrote:
> >>>>>>> Looking into this. Sorry for the late response, we were moved into a
> >>>>>>> different office over the weekend.
> >>>>>>>
> >>>>>>> On Fri, May 8, 2015 at 1:01 PM, Jan S Rellermeyer
> >>>>>>> <rellermeyer at us.ibm.com> wrote:
> >>>>>>>> I am helping people in IBM who have encountered a hotspot bug that
> >>>>>>>> surfaces
> >>>>>>>> when using bitwise rotations (such as through Integer.rotateRight).
> >>>>>>>> I
> >>>>>>>> have
> >>>>>>>> attached a small test program that illustrates the problem. When
> >>>>>>>> running
> >>>>>>>> this on Power LE (I don't think that anybody tried on BE, though)
> >>>>>>>> the
> >>>>>>>> results of the hash function are incorrect.
> >>>>>>>>
> >>>>>>>> The bug goes away when disabling inlining. After digging through the
> >>>>>>>> generated code I found out that it contained some suspicious fnmadd
> >>>>>>>> instructions where you would rather expect some kind of left rotate.
> >>>>>>>> I
> >>>>>>>> could
> >>>>>>>> track down that the bug was caused by the immediate value for the
> >>>>>>>> right
> >>>>>>>> shift constant of what should be a rlwinm node to be negative and
> >>>>>>>> thereby
> >>>>>>>> bleeding into the opcode (which unfortunately still created a valid
> >>>>>>>> Power
> >>>>>>>> instruction, namely the fnmadd). Running with a fastdebug build
> >>>>>>>> causes
> >>>>>>>> an
> >>>>>>>> assertion to fail.
> >>>>>>>>
> >>>>>>>> The attached patch does fix the problem and so does an alternative
> >>>>>>>> patch
> >>>>>>>> that replaces the URshift with a UShift but I am not entirely sure
> >>>>>>>> if
> >>>>>>>> this
> >>>>>>>> really fixes the root cause or rather just prevents the rotlI
> >>>>>>>> instruction
> >>>>>>>> from being matched by the ReduceInst.
> >>>>>>>>
> >>>>>>>> --Jan.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> Dr. Jan S. Rellermeyer
> >>>>>>>> IBM Research
> >>>>>>>> RSM - Austin Research Lab
> >>>>>>>> rellermeyer_at_us.ibm.com
> >>>>>>>> The University of Texas at Austin
> >>>>>>>> Adjunct Assistant Professor
> >>>>>>>> jrellerm_at_cs.utexas.edu
> >>>>>>>>
> >>>>>>>> (See attached file: hash.java)(See attached file: rotl.patch)
> >>>>
> >>>>
> >>>>
> 

-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07


From bertrand.delsart at oracle.com  Thu May 28 13:52:12 2015
From: bertrand.delsart at oracle.com (Bertrand Delsart)
Date: Thu, 28 May 2015 15:52:12 +0200
Subject: RFR [S]: 8079473: allow demangling to be optional in
	dll_address_to_function_name
Message-ID: <55671D8C.2080208@oracle.com>

Hi all,

Here is a webrev that add a 'demangle' argument to 
dll_address_to_function_name so as to make the demangling optional. The 
webrev also includes some limited cleanup and fixes an issue I noticed 
on windows.

https://bugs.openjdk.java.net/browse/JDK-8079473
http://cr.openjdk.java.net/~bdelsart/8079473/

Fix is targeted at JDK9 and will be pushed through hs-rt.

This enhancement is currently used only by some closed extensions. It 
has been validated on linux and the fix is very similar on all platforms 
except AIX.

I've quickly implemented the AIX version but could not test it. Let me 
know if you would prefer me to remove the AIX code and just ensure that 
the 'demangle' argument is ignored on that platform.

The cleanup is about optional arguments to decode, which were redefined 
in the overridden versions for the different operating systems. To avoid 
weird behaviors, the default values should be defined only in the 
toplevel class AbstractDecoder, not the subclasses (but that was OK as 
long as the default values were identical)

On Windows, I discovered a bug while adding the non-demangling support.
This old code from WindowsDecoder::decode should not behave as expected 
if really used:
         if (demangle(pSymbol->Name, buf, buflen)) {
           jio_snprintf(buf, buflen, "%s", pSymbol->Name);
         }
The code is supposed to write in 'buf' the raw form when the demangling 
fails. Hence, the jio_snprintf should be executed when demangle returns 
false. The code above fails to properly set buf when the demangling 
fails and also replaced the demangled form by the raw form when 
demangling succeeded.

It should have been "if (! demangle(...". With my extension, it now is 
"if (!(demangle_name && demangle(...", like on other platforms.

Best regards,

Bertrand.
-- 
Bertrand Delsart,                     Grenoble Engineering Center
Oracle,         180 av. de l'Europe,          ZIRST de Montbonnot
38330 Montbonnot Saint Martin,                             FRANCE
bertrand.delsart at oracle.com             Phone : +33 4 76 18 81 23

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged
information. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply email and destroy all copies of
the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~