RFR(S): 8252696: Loop unswitching may cause out of bound array load to be executed
Roland Westrelin
rwestrel at redhat.com
Thu Sep 3 15:35:21 UTC 2020
Hi Christian,
Thanks for looking at this.
> Nice analysis! This fix sounds reasonable to me. Have I understood that
> correctly that in your testcase, the main loop is just unrolled enough
> such that the loop nodes can be removed (so no over-unrolling)?
Right.
>> [..] and then eliminates the
>> dominating ones that it finds useless. Removing dominated predicates
>> that have no control dependent data nodes the way it's done in the
>> current logic is suspicious: data nodes are sometimes logically
>> dependent on multiple range checks but control dependent on only one.
>
> That's a valid point. Is there a better way we could find out which
> predicates are useless after cloning them to the slow and fast loop or
> is it either way not a problem to keep the original ones alive?
AFAIU, that's not a problem with the patch I propose which only clones
the skeleton predicates. All of them are required to be copied in case
of unrolling.
> I agree, I think I added this back there because I was temporarily
> modifying the old_new mapping in a non-conform way on L302. So, I just
> wanted to be sure that everything is reset and works as intended. But
> I'm also fine with just removing this assertion code.
Should I remove L302 as well? I'm confused by what's going on here.
> Some small comment:
> - You probably don't need the assertion on L257 in loopPredicate.cpp as
> you are already checking it in the if-condition on L253.
Right. I'll remove it.
> - Same file, you should update the assert message on L268 to something
> like "... projection of an If node".
I'll make that change too.
Roland.
More information about the hotspot-compiler-dev
mailing list