RFR(S): 8244086: Following 8241492, strip mined loop may run extra iterations
Roland Westrelin
rwestrel at redhat.com
Thu Apr 30 11:48:46 UTC 2020
> Maybe another option would be to recognize loops which are affected by this problem and live with having a safepoint in the body (skip LSM).
> AFAICS "for" loops have the check at the beginning and should not be affected.
That requires pattern matching to find a dominating check. That pattern
matching has to be robust enough. I gave it a try and it's
straightforward for a simple:
for (int i = start; i < stop; i++) {
with:
{
bool found = false;
Node* temp_cmp = cmp->clone();
int limit_edge = cmp->find_edge(limit);
assert(limit_edge == 1 || limit_edge == 2, "");
temp_cmp->set_req(limit_edge == 1 ? 2 : 1, init_trip);
Node* dom_cmp = _igvn.hash_find(temp_cmp);
if (dom_cmp != NULL) {
Node* temp_test = test->clone();
temp_test->set_req(1, dom_cmp);
Node* dom_cmp = _igvn.hash_find(temp_test);
if (dom_cmp != NULL) {
temp_cmp->destruct();
temp_test->destruct();
for (DUIterator_Fast imax, i = dom_cmp->fast_outs(imax); i < imax && !found; i++) {
Node* u = dom_cmp->fast_out(i);
if (u->is_If()) {
ProjNode* proj = u->as_If()->proj_out(back_control->as_Proj()->_con);
proj->dump();
if (is_dominator(proj, x)) {
found = true;
}
}
}
}
}
}
But that fails for:
public static int hashCode(byte[] value) {
int h = 0;
for (byte v : value) {
So it feels like quite a bit of extra complexity and it could backfire
if the pattern matching is not robust enough.
Roland.
More information about the hotspot-compiler-dev
mailing list