RFR: 8221647: [lworld] Performance regression due to the fact that check if array is array of values is not hoisted out of the loop.
rwestrel at redhat.com
Tue Jun 11 15:12:41 UTC 2019
> 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.
> - 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.
More information about the valhalla-dev