merge of types in ConditionalPhaseElimination

[Lukas Stadler]

Hi Miguel,

yes, this is a bug… thanks for the hint!

- Lukas

On Jul 20, 2013, at 6:49 PM, Garcia Gutierrez Miguel Alfredo <miguelalfredo.garcia at epfl.ch> wrote:

> 
> Still figuring out the workings of ConditionalEliminationPhase, I have a question regarding
> 
>        public boolean merge(MergeNode merge, List<State> withStates) {
> 
> which merges among other things the "known (object) types" over all incoming states:
> 
>            for (Map.Entry<ValueNode, ResolvedJavaType> entry : knownTypes.entrySet()) {
>                ValueNode node = entry.getKey();
>                ResolvedJavaType type = entry.getValue();
> 
>                for (State other : withStates) {
>                    ResolvedJavaType otherType = other.getNodeType(node);
>                    type = widen(type, otherType);
>                    if (type == null) {
>                        break;
>                    }
>                }
> ------------>   if (type == null && type != node.objectStamp().type()) {
>                    newKnownTypes.put(node, type);
>                }
>            }
> 
> My reading of the above is:
>  (1) fold the meet-operation across all incoming states.
>  (2) Two cases:
>      (2.a) the accumulated type is null (ie, there's no common ancestor, for example because some of the incoming states lack entries in "knownTypes").
>      (2.b) non-null, and moreover a type more precise than Object has been inferred. That's the merged type we want to track in the merged state.
> 
> Getting to the code, there appears to be a typo (the arrow marks the spot). I guess the intention is adding an entry for the "accumulated type" to "newKnownTypes" (case 2.b). If so, that line should read:
> 
>                if (type != null && type != node.objectStamp().type()) {
> 
> 
> 
> Miguel
> 
> --
> Miguel Garcia
> Swiss Federal Institute of Technology
> EPFL - IC - LAMP1 - INR 328 - Station 14
> CH-1015 Lausanne - Switzerland
> http://lamp.epfl.ch/~magarcia/