C2: Unrolling and hoisting trivial expressions out of loops
Andrew Haley
aph at redhat.com
Sat Apr 28 07:45:57 UTC 2018
On 04/27/2018 08:54 PM, John Rose wrote:
> On Apr 27, 2018, at 11:08 AM, Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
>>
>> I don't see it on SPARC
>
> I think this behavior is controlled by Matcher::clone_address_expressions,
> which is defined in <arch>.ad.
Interesting, Thanks, I'll kick that around and see what it does. The
problem seems to have been exacerbated by the fact that we seem to be
unrolling a lot more than we used to. This is in general a good
thing, I suppose, especially if unrolling is driving vector
generation.
> There is a processor-dependent decision about expressions which might
> be address expressions: Should we common them up (good for RISC)
> or keep separate instances under their consuming instructions (good for
> CISC)?
Mmm, but commmoning then up isn't great in this case, which is typical
RISC addressing. It's never going to be great when you have 16-times
unrolling of a loop with two array inputs on a machine with fewer than
32 address registers.
> If they are commoned they are code-generated into registers.
> Otherwise, they should be matched into instruction definitions. If the
> latter step fails, you get duplicated address generation code, which
> looks bad, instead of duplicated addressing modes, which doesn't
> look bad. Of course it is a processor-dependent decision what exactly
> constitutes an address expression.
Sure. It's a tricky issue to get right, and I have a horrible feeling
that if I tweak this it'll cause regressions elsewhere.
--
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the hotspot-compiler-dev
mailing list