A simple optimization proposal
rednaxelafx at gmail.com
Wed Feb 12 15:05:05 PST 2014
Thanks for looking at it. I added the other cases and added a missing
The patch is updated in place: https://gist.github.com/rednaxelafx/8964030
Ran a few small cases on case 1 and 3 manually and the resulting IR graphs
were right. I wasn't able to check the case 2 ("Change ((x & m) u<= m) to
always true") though, I don't know what Java code could be compiled into
On Wed, Feb 12, 2014 at 2:00 PM, Vladimir Kozlov <vladimir.kozlov at oracle.com
> Looks reasonable. Kris, you need also look for other patterns listed in
> On 2/12/14 12:39 PM, Krystal Mok wrote:
>> Hi Martin and John,
>> I did a quick-and-dirty patch and it seems to work:
>> If it looks right then I'll refactor that code a little bit and send it
>> in for official review.
>> - Kris
>> On Wed, Feb 12, 2014 at 11:17 AM, John Rose <john.r.rose at oracle.com
>> <mailto:john.r.rose at oracle.com>> wrote:
>> It's totally reasonable, and is already filed as an RFE (please
>> comment on it!):
>> -- John
>> On Feb 12, 2014, at 9:40 AM, Martin Grajcar <maaartinus at gmail.com
>> <mailto:maaartinus at gmail.com>> wrote:
>> Most hash tables are power-of-two sized so that they can use
>>> masking for the access. It looks like the bounds check doesn't get
>>> eliminated, although it could be.
>>> Based on the equivalence |a[x & (a.length - 1)]| throws if and
>>> only if |a.length == 0|, I'm proposing this simple algorithm:
>>> * For each array access, check if the index has been computed
>>> via a bitwise and.
>>> * If so, check if either of the operands was computed as length
>>> minus one.
>>> * If so, replace the bounds check by a zero-length check.
>>> This zero-length check can then be easily moved out of the loop by
>>> the existing optimizations.
>>> I hope I'm not talking non-sense. For more details see
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-compiler-dev