On 04/29/2013 06:56 AM, Wei WU(吴伟) wrote:
Hi,
On Sat, Apr 27, 2013 at 5:19 PM, Jan de Mooij <[email protected]> wrote:
Hi,
This looks really interesting. Not emitting code for cold branches could
not only help LICM and GVN but also register allocation by avoiding
unnecessary spills and moves.
However, my main concerns are:
(2) Instead of pruning MIR from the graph, IonBuilder could just
immediately terminate "cold" basic blocks (very similar to what it does
when it reaches a JSOP_RETURN or JSOP_THROW). Just add a new MIR
instruction that unconditionally bails out.
This approach is fresh to me and seems easier than pruning. I think they
share some common tasks when a basic block is marked "cold": remove the
instructions in the basic block, update use-def chains, reduce type sets
and phi nodes. Pruning MIR from the graph have more work to do and might
gain extra optimization opportunities.
I would like to implement the "terminate" approach first and see whether it
works or not. Then we can implement the "pruning" approach quickly, based
on the "terminate" approach, if necessary.
I am not a big fan of adding that to IonBuilder, the main reason is that
IonBuilder is currently a huge pieces of code and I wish we could move the
Stack-based type information and MIR specialization out of the way, as
separated MIR phases.
The other reason is that it would be harder to integrate the branch pruning
inside IonBuilder as we are trying to recover information from the bytecode,
and we are extremely tied to the bytecode interpretation, I am afraid this
will imply changes to the re-AST-ify logic.
(3) Before implementing anything, it would be good to look at some
benchmarks (Kraken, Octane, maybe Emscripten code) and see where we expect
the main perf wins. Then you can hack/prototype something just for that
particular case and see what happens.
Currently I'm searching Kraken to find some functions for case study but
the progress is quite slow. I could not find such profiling tools that can
show the frequencies of each branch so I literally read the JavaScript code
to make guesses. I use the Gecko profiler, JIT Inspector and IonGraph to
accelerate my work. Could you recommend me some utilities? That would be
great help.
I made some profiling on PdfJS back in Novemeber. The idea was to have a
uniq identifier for each basic block of each script to dump the profile
information data. (see masm.printf and CogeGenerator::generateBody)
The raw info that I have does not alias basic blocks between compilations,
but I am sure we can add it on the current results that I put online[1].
This file contains what would have been stored by an infinite buffer
collecting the block numbers visited in Ion.
It would be interesting just to note the number of blocks which are never
visited in these benchmarks as well as if some path are rarely visited and
the impact on performances if we were to bailout on these without the
ability to re-enter. (such as we probably don't want to bail if the next
loop is hot and we do not have an OSR entry-point for it)
[1] http://people.mozilla.org/~npierron/pdfjs-pgo.tar.bz2
--
Nicolas B. Pierron
_______________________________________________
dev-tech-js-engine-internals mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
