Re: Speed of java interpreter in libjava/interpret.cc

[Michael Matz <matzmich at cs dot tu-berlin dot de>]

Hi,

On Tue, 23 Jan 2001, Brad Lucier wrote:
> alphaev6-unknown-linux-gnu; on comparing the .s files, I found no
> substantive differences in the generated code.  (This may not be what
> people expect; the address of insn_target is reloaded for each bytecode
> in the interpreter, for example.) So GCSE doesn't seem to help this
> code substantially, but it doesn't seem to pessimize it, either.

That gcse is of no help here might also be due to the very small set of
expressions GCSE is applied at all. E.g. on x86 no normal PLUS expressions
will be GCSE'ed because they reside in 
(PARALLEL([set dest=(PLUS...)][CLOBBER FLAGS])), and GCSE is not applied
to PARALLEL's at all.

> There is an extension of LCM (the GCSE method used in gcc) to control

Unfortunately in gcc edge based LCM is used, but the research I'm aware of
(including that new LCM) all is done with normal block-based LCM. There
are very few references to edge-based LCM, e.g. in Morgan's book, but
there only the results are given, no connection to the other method. And
the paper about it (in SIGPLAN notices) I can't find electronically, so I
need to wait till tomorrow, when I get to university.

> flow graphs with critical edges (e.g., computed goto's).  Perhaps when
> (if?) that algorithm is implemented, one will find improvements to the

If I can apply Ruething's results to edge based LCM it will be
implemented.


Ciao,
Michael.