Duplicate :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
While working on JDK-8249607 it was not clear if the code starting at L1399: // See if a shared loop-varying computation has no loop-varying uses. // Happens if something is only used for JVM state in uncommon trap exits, // like various versions of induction variable+offset. Clone the // computation per usage to allow it to sink out of the loop. if (has_ctrl(n) && !n->in(0)) {// n not dead and has no control edge (can float about) is really doing what it is supposed to do. There are several things to be checked and might to be reworked: - Revisit the entire cloning optimization: - Is it really required or would other loop opts move loads out of the loop anyways if there are no uses inside? - What if there are some uses inside and outside, is it really beneficial to do the cloning and possibly ending up with multiple loads? If optimization is required: - We should rethink the yanking part as it does not prevent the nodes to be put back on the worklist and might block some optimizations. Is there another way to prevent nodes without control to float back into the loop? Maybe adding a cast node with an explicit control? - Make sure to not pin loads inside the loop if x_ctrl turns out to be a node inside the loop at the end (if that is not already guaranteed) - Make sure not to pin loads in an outer strip mined loop if they do not have a use there (i.e. think about late_load_ctrl, maybe have a look at idea in http://cr.openjdk.java.net/~chagedorn/8249607/webrev.01/ which tackles that problem)
|