G'day all.

On Thu, Apr 18, 2002 at 09:35:11AM -0400, Jason Gloudon wrote:

> Having registers provide the destination for some branches makes it
> possible to generate code that eliminates most of the comparisions
> needed to implement C style case/switch statements, so this is not a
> useless feature.

I did think of this.  I'm not entirely sure what kind of code you're
planning to generate here, but all the ways I could think of generating
code for C-style switches were inferior to having two special ops to
implement them directly: one for "dense" switches, which can be
implemented as a domain check followed by array lookup, and one for
"sparse" switches which can be implemented as a linear or binary search.

What code did you have in mind?

> >     - It is in general impossible for an optimizer to determine
> >       where the branch targets are if you allow registers as
> >       branch targets.  Even when it's possible, it's too hard.
> 
> That's why a compiler would put information about possible targets of branches
> somewhere available to the optimizer.

I'm leaning towards the view that a simple optimizer shouldn't need
compiler support beyond obeying the pbc file format.  More information
might be useful, but it shouldn't require it.

Part of my motivation behind this view is the performance of Sun's
"Hotspot" JVM, which can, in principle, profile code and run an
optimization pass at run time if it finds a "hot spot".  Parrot
shouldn't necessarily aim for this but I think we would be well
advised not to make the design of Parrot fundamentally incompatible
with the technique.

> >     - Eliminating it speeds up life.pasm by about 5-10% according
> >       to my highly unscientific benchmark.
> 
> What about mops.pasm ?

5% speedup again.

> The speedup (if real) is probably just a side-effect of
> deleting the code for those ops.

Of course.  It's entirely a product of bloat reduction.  I should point
out here that the 5-10% speedup is entirely "real time", not "user
time".  It's still time that could be spent doing something else. :-)

Cheers,
Andrew Bromage

Reply via email to