two questions about ConditionalEliminationPhase
Garcia Gutierrez Miguel Alfredo
miguelalfredo.garcia at epfl.ch
Sun Jul 14 13:59:33 PDT 2013
After staring for what seemed like an eternity to ConditionalEliminationPhase, it slowly began to make sense. But not quite, as the questions below show.
/--------------------------\
|Question 1: Is this a bug?|
\--------------------------/
One of the cases that
private void registerCondition(boolean isTrue, LogicNode condition, ValueNode anchor) {
handles is
} else if (condition instanceof ObjectEqualsNode) {
where the consequences of the object-equality check are propagated.
In case of inequality, and one of the comparands known to be null, the code below gains information about the other comparand (ie, must be non-null). That's the idea, right?
if (state.isNull(x) && !state.isNonNull(y)) {
metricObjectEqualsRegistered.increment();
--------------> state.addNullness(true, y);
} else if (!state.isNonNull(x) && state.isNull(y)) {
metricObjectEqualsRegistered.increment();
--------------> state.addNullness(true, x);
}
However instead of recording non-nullness, the lines with an arrow above mark nullness. Looks to me it should read: `state.addNullness(false, ` etc. Comments are welcome to understand what's going on.
/----------------------------\
|Question 2: Could this work?|
\----------------------------/
I haven't looked into all phases, thus the suggestion below could be covered already. Let's see.
In:
private void registerCondition(boolean isTrue, LogicNode condition, ValueNode anchor) {
three shapes of the condition are of interest (InstanceOfNode, IsNullNode, ObjectEqualsNode) because they allow trickling information from the whole condition down to its components.
Question: could LogicBinaryNode also be handled? For example,
(a) a LogicConjunctionNode known to be true allows establishing all its components to be true;
(b) a LogicDisjunctionNode known to be false allows establishing all its components to be false;
(Not sure whether the extra precision pays off, my question is rather about whether that could be done in principle).
And now the kudos: Cool stuff!
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