diff options
| author | Miguel Garcia <miguelalfredo.garcia@epfl.ch> | 2012-01-16 15:48:02 +0100 |
|---|---|---|
| committer | Miguel Garcia <miguelalfredo.garcia@epfl.ch> | 2012-01-16 15:48:02 +0100 |
| commit | ba00a5b9344275b64935cf18191201cc54d59cdb (patch) | |
| tree | 1951a45d62327382e5cc91a041cc4b86a5f9c4f0 /build.number | |
| parent | ac11155b3fae83e7977b58514ea10ca2a0c46a84 (diff) | |
| download | scala-ba00a5b9344275b64935cf18191201cc54d59cdb.tar.gz scala-ba00a5b9344275b64935cf18191201cc54d59cdb.tar.bz2 scala-ba00a5b9344275b64935cf18191201cc54d59cdb.zip | |
bringing down -Yinline time by 33%
After inlining one ore more callsites, Inliner runs anew a type-flow analysis for the same method, ie. the previous solution is discarded although it's a subset of that needed after the inlining(s). Background in: http://lamp.epfl.ch/~magarcia/ScalaCompilerCornerReloaded/2011Q4/Inliner.pdf
Instead, we invalidate only the fragment of the CFG affected by inlining (the basic block where inlining occurred and newly added basic blocks) and let the iterative dataflow analysis start from there. It reaches the fixpoint faster.
The inlining decisions thus made are exactly the same as with the slower version, see -Ylog:inliner, with a focus on lines starting with "[log inliner] Inlining"
review by @VladUreche @dragos @paulp
Diffstat (limited to 'build.number')
0 files changed, 0 insertions, 0 deletions