CSE, loops, and array accesses

Edward Nevill edward.nevill at gmail.com
Thu Oct 1 13:36:32 UTC 2015


On Thu, 2015-10-01 at 14:19 +0100, Andrew Haley wrote:
> On 10/01/2015 02:00 PM, Edward Nevill wrote:
> > Try the following patch, it should generate the code you want.
> 
> OK, so perhaps the question is how to fix this in the form of a patch
> which can go into JDK9.
> 
> But there is a deeper question: why is ((A+B)+con) so tightly bound
> that the constant add can never be CSE'd?  I guess there is some
> special-case code somewhere which detects address this case.

I guess the reason for rewriting ((A+con)+B) to ((A+B)+con) is to match Intel's complex addressing mode [reg + reg<<N + M].

There is an existing predicate in XXX.ad

bool Matcher::narrow_oop_use_complex_address()

We could generalise this to something like

bool Matcher::has_complex_address()

and use that to predicate whether or not to do the rewrite.

I think this would be a win on Sparc and PPC also as they don't have the above addressing mode. But I don't have any such HW to test.

All the best,
Ed.




More information about the hotspot-compiler-dev mailing list