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