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