fewer tricks in ConditionalEliminiationPhase

Garcia Gutierrez Miguel Alfredo miguelalfredo.garcia at epfl.ch
Sun Feb 9 12:35:53 PST 2014


Looking at ConditionalElimination, in those cases where it detects a more precise stamp than the current stamp, it's not possible for other phases to act upon that information.

For example, ConditionalElimination detects (but other phases don't) that in the then-branch below:

if (input instanceof X) {
  ...
}

the value of "input" has a more precise stamp. How about conveying that more precise stamp to other phases by:

  (1) finding those usages (of "input") enclosed in the then-branch,
  (2) have those usages use instead a PiNode that tightens to the more precise stamp.

With that, any optimization (present or future) that might benefit from the more precise stamp will get applied, without ConditionalElimination knowing about it.

Say, a future optimization that (somehow) detects more precise return types for monomorphic callsites.

Or InstanceOfNode canonicalization.

How to implement the above? Here's an idea. Given that ConditionalElimination.node(FixedNode) already knows:
  - the State    for that FixedNode
  - the inputs() for that FixedNode,
how about comparing, for each input-node,
  - the stamp as per input-node vs the stamp as per current-state
replacing the particular input in question by a PiNode if possible.
The above guarantees that only those usages where the tightened stamp is known to hold are actually tightened.

In case the above works (comments are welcome!) then State could also be extended to track equalities, to replace this time not stamps but values. For example:

if (a == b) { // ObjectEqualsNode or integrals
  // usages of, say, b can be replaced with "a"
  // (which might trigger further simplifications)
}


Miguel


--
Miguel Garcia
Swiss Federal Institute of Technology
EPFL - IC - LAMP1 - INR 328 - Station 14
CH-1015 Lausanne - Switzerland
http://lamp.epfl.ch/~magarcia/


More information about the graal-dev mailing list