Anton Ertl wrote:
> I am currently thinking of the following test to check the validity
> and completeness of the arrangements of a particular primitive: Take
> all the labels we have, and sort them.  If the labels of one primitive
> (we have three, one at the start, one near the end, and one at the end
> just before a superfluous asm statement) are consecutive, without an
> intervening label of another primitive, then we assume that it is ok,
> otherwise it is not.  I fear this assumption will not be conservative
> enough for gcc-3.4, but that's the best I can think of right now.  Any
> other ideas?
> 
> If it is ok, we use the start and end labels as suggested by Matthias.

I have now implemented a variation of this idea: Instead of requiring
that the primitive ends in its own end label, any end label will do.
For gcc the end label looks as if it belongs to the next primitive, so
since it rearranges the primitives, it will also rearrange the end
labels; but it's pretty sure that each primitive is followed by some
end label.

Here are some performance results for a 2.26 GHz Pentium 4 (all with
--enable-force-reg):

      development version gforth-0.6.1
       gcc-3.3 gcc-2.95.1 gcc-2.95.1
siev   0.32      0.25      0.24
bubble 0.36      0.28      0.28
matrix 0.18      0.19      0.19
fib    0.40      0.36      0.35

So for these benchmark gcc-3.3 provides a slowdown of up to a factor
1.3 over gcc-2.95.1, even after the tunbing I did.  Since they seem to
be the same speed without dynamic code generation (actually, gcc-3.3
seems to be a little faster there), the slowdown probably comes from
the reduced opportunities for dynamic code generation thanks to the
various code rearrangements gcc-3.3 performs (whereas gcc-2.95.1 is
much more predictable).

Probably the most impact is from rearrangements that make some
primitives (mostly 0branch and friends) non-contiguous, some comes
from confusing the validity and completeness checker (which has to err
to the side on less dynamic code generation when in doubt).

Here are numbers for gforth-fast --no-dynamic:

       gcc-3.3 gcc-2.95.1
siev   0.61     0.63
bubble 0.77     0.80
matrix 0.94     0.95
fib    0.88     0.89

In any case, I'll set out to do a 0.6.2 release now.

- anton

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to