RFR: 8221647: [lworld] Performance regression due to the fact that check if array is array of values is not hoisted out of the loop.

[Roland Westrelin]

Hi Tobias,

> Were you able to reproduce the problem of flattened array accesses being incorrectly reordered? I.e.
> do we have a regression test for that?

I was not when I gave it a try.

> graphKit.cpp:
> - line 3405: I think you should use GraphKit::load_object_klass or LoadKlassNode::make.

But then for compressed class pointers, that would return a decode node
when what I need is the LoadKlassN.

> Also, I see build failures on Windows:
>
> jib > t:/workspace/open/src/hotspot/share/opto/compile.cpp(3968): error C2220: warning treated as
> error - no 'object' file generated
> jib > t:/workspace/open/src/hotspot/share/opto/compile.cpp(3968): warning C4293: '<<': shift count
> negative or too big, undefined behavior

Hard for me to test builds on windows. I changed 1L << to be ((jlong)1)
<< instead. Not sure if that's sufficient.

> And a failure with TestLWorld:

I think the problem here is that G1 barriers get in the way of
optimizations so the IR differs when it's compiled with parallel GC
enabld compared to G1 enabled. I changed the match rule to 2 match
rules, one for G1 enabled and one for G1 disabled.

New webrev:
http://cr.openjdk.java.net/~roland/8221647/webrev.01/

incremental:

http://cr.openjdk.java.net/~roland/8221647/webrev.00-01/

Roland.