Mercurial > hg > graal-compiler
comparison ProblemsIdeas.txt @ 3521:82266dbf5a5a
WIP : updated loop counter detection, added Basic and Derived induction variable framework
| author | Gilles Duboscq <gilles.duboscq@oracle.com> |
|---|---|
| date | Tue, 09 Aug 2011 18:53:11 +0200 |
| parents | 0ffcce571d09 |
| children |
comparison
equal
deleted
inserted
replaced
| 3519:16cee060c446 | 3521:82266dbf5a5a |
|---|---|
| 9 | 9 |
| 10 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 | 10 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 |
| 11 | 11 |
| 12 | 12 |
| 13 * Deopt caused by profiling can interfer with later optimisations | 13 * Deopt caused by profiling can interfer with later optimisations |
| 14 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 | 14 Example : 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 |
| 15 | |
| 16 * Canonicalization & DeadCodeElimination should play better together | |
| 17 Somtimes the graph does not get completely canonical after a CanonicalizationPhase followed by a DeadCodeEliminationPhase because DCE can transform some Phi into one of their input value because of the removal of a branch, if this transformation gives a canonicalization opportunity, it will never be used. We could apply Canonicalization followed by BCE until we reach a fixed point but that's probably not very efficient. | |
| 15 | 18 |
| 16 Ideas | 19 Ideas |
| 17 ===== | 20 ===== |
| 18 | 21 |
| 19 * Always inline 'specialization' methods | 22 * Always inline 'specialization' methods |