--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/ProblemsIdeas.txt	Tue Jul 19 13:48:43 2011 +0200
@@ -0,0 +1,51 @@
+Problems
+========
+
+* -Xcomp + synchronized method + unresolved type => deopt to bci -1
+  Example : try "runfop.sh -G:-Inline -Xcomp" should fail on the compilation of org.apache.xmlgraphics.util.Service.providers(java.lang.Class, boolean)
+  
+  The first bytecode of the method is NEW (java.lang.StringBuffer)it will deopt because java.lang.StringBuffer is not resolved, the logic in append(FixedNode) will go back until the start node, detaching the MonitorEnter from the start node and attaching the Deopt instead.
+  Deopt will now get the FrameState generated by LIRGenerator in setOperandsForLocals which is bci -1 for a synchronized method.
+
+  Can interpreter handle bci -1 for synchronized methods ? if this is the case, the corresponding assert in LIRGenerator.visitDeoptimize should be removed as bci -1 should now only be used for synchronized entry points and not for exception handling or anything else
+
+
+* Deopt caused by profiling can interfer with later optimisations
+  Exmple : have a look to some of the visit methods in avrora.arch.legacy.LegacyInterpreter sometimes if constructs which are used to materialize some booleans have a Deopt branch which prevents us from detecting an opportunity for a MaterilizeNode canonicalization. As long as the MaterializeNode itself doesnt get canonicalized away and in the end translates to jumps in the final assembly this doesnt really matter but it may if we optimise the emitted assembly
+
+Ideas
+=====
+
+* Always inline 'specialization' methods
+  Example :
+  public void foo(int a) {
+      foo(a, 1); // invoke 1
+  }
+
+  public void foo(int a, int b) {
+      foo(a, b, false); // invoke 2
+  }
+
+  public void foo(int a, int b, boolean c) {
+      // ...
+  }
+ 
+  Here invoke 1 and 2 should always be inlined regardless of the size of the inlined graph/method size and without increasing the inlining depth
+
+
+* 'computable' slots in Framstates/debug info
+
+  Framestates/debug info will keep some values live for longer than they should because the values are needed for exemple for a very unlikely Deopt, this increases the pressure on register allocator.
+  In the current system Deopt is the unlikely/slow path so maybe we can make it a bit slower to avoid this problem and increase fast path performances.
+  An idea would be to insert an 'expression' in some slots instead of value referances, the expression would use values that have to be live at this point for program semantics reasons.
+  Expressions would then be evaluated by the runtime when the framestate values are needed. Expression operators probably have to be kept simple (non-trapping arithmetics)
+  This could be done by deopting to some deopt handler that will fixup the computable slots, this would probably require less runtime hacking. For exemple an object containing the informations necessary to fixup the framestate could be inserted in one of the framestate solts and then used by a deopt handler called in the same way than the deopt handler example.
+
+
+* Profilable expressions
+
+  Some optimizations may benefit from knowing is some assumption can be done. For exemple some loop optimisations may want to know the likelyhood of 2 values being aliased so that it can know if inserting a deopt-if-aliased guard is really beneficial.
+  This kind of information can not always be derived just from branch probabilities and it would be interesting to be able to ask the runtime to profile an expression, the simplest version would be to generate a boolean expression and get the probability for it being true.
+  This requires going through the compiler and asking for further profiling there are 2 main options here :
+   - Reprofile the method in interpreter with the new profiled expression (we may modify the method bytecode to insert a conditional branch on the expression we want to profile, thus using the classical branch probability infrastructure)
+   - insert a profiling snippet in the compiled code and ask runtime to recompile the method after N executions

--- a/graal/com.oracle.max.graal.compiler/src/com/oracle/max/graal/compiler/ir/Compare.java	Mon Jul 18 13:30:37 2011 +0200
+++ b/graal/com.oracle.max.graal.compiler/src/com/oracle/max/graal/compiler/ir/Compare.java	Tue Jul 19 13:48:43 2011 +0200
@@ -193,7 +193,7 @@
             } else if (compare.y().isConstant() && compare.x() instanceof NormalizeCompare) {
                 return optimizeNormalizeCmp(compare, compare.y().asConstant(), (NormalizeCompare) compare.x());
             }
-            if (compare.x() == compare.y() && compare.x().kind != CiKind.Float && compare.x().kind != CiKind.Double) {
+            if ((compare.x() == compare.y() || compare.x().valueEqual(compare.y())) && compare.x().kind != CiKind.Float && compare.x().kind != CiKind.Double) {
                 return Constant.forBoolean(compare.condition().check(1, 1), compare.graph());
             }
             return compare;

--- a/graal/com.oracle.max.graal.compiler/src/com/oracle/max/graal/compiler/ir/EndNode.java	Mon Jul 18 13:30:37 2011 +0200
+++ b/graal/com.oracle.max.graal.compiler/src/com/oracle/max/graal/compiler/ir/EndNode.java	Tue Jul 19 13:48:43 2011 +0200
@@ -79,6 +79,10 @@
 
     @Override
     public Iterable< ? extends Node> cfgSuccessors() {
-        return Arrays.asList(this.merge());
+        Merge merge = this.merge();
+        if (merge == null) {
+            return Collections.emptyList();
+        }
+        return Arrays.asList(merge);
     }
 }