loop invariant code motion and the jit

[Vitaly Davidovich]

I agree that this particular example isn't worth any trouble, but it seems
to be showing a bigger problem with how add nodes interact with LICM.  If
there are several LI expressions that materialize in the body, then the
total tax, particularly if the loop is otherwise cheap, adds up.  GCC,
LLVM, and ICC all hoist similar C code (some of these actually go even
further with optimizations, but that's beside the point).  I think it's a
bit sad that such an obvious LICM opportunity is missed by the highest tier
compiler in Hotspot.  That's not to say a fix isn't risky, but just an
observation from the sidelines.

On Wed, Jan 18, 2017 at 10:52 AM, Roland Westrelin <rwestrel at redhat.com>
wrote:

>
> > Roland, would it be possible to have IdealLoopTree reassociate the
> > operations and then mark the AddNode to tell it to not perform
> > canonicalization again?
>
> Possibly eventhough AFAICT, current c2 code avoids that kind of
> tricks. Anyway, if that was fixed one way or another, we would also need
> to verify that it doesn't cause any regression so it's more work than it
> may appear and in this particular case I'm not sure it's worth the trouble.
>
> Roland.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20170118/ad9141ea/attachment.html>