SEQUENCEs
law@redhat.com
law@redhat.com
Tue Jun 11 07:22:00 GMT 2002
In message <3D05D7B1.DFC1D0B6@superh.com>, Joern Rennecke writes:
> > >it creates. For a bootstrap of i686-pc-linux-gnu, I simply recorded the
> le
> > ngth
> > >of each sequence closed in end_sequence.
> > >
> > ># insns 1 2 3 4 5 6 7 8 9 10+
> > >%sequences 80 11 1.2 1.5 1.5 1.7 2.4 0.5 0.4 0.2
> > >
> > >
> > >This clearly shows that most sequences are very short -- so the cost of
> > >find the end really should not be that high in few those cases where we
> > >actually
>
> Note that the picture is likely to be different for targets that need to
> synthesize
> lots of operations, e.g. do divide by inverse multiply, and multiply by
> shifts & adds, and do shifts in serveral steps.
The PA does many of things. Hell, even many simple moves are handled with
a sequence on the PA. If you'd like, I can easily run this test on a target
of your choice when building newlib or somethign like that. It's not
dreadfully
hard.
> If you go with my scheme to make end_sequence return the struct sequence,
> the case of one insn is just like the case of 2, 3, 4 or whatever amount
> of insns. The only sepcial case is 0 insns.
How about you do it? It's clearly an additional optimization beyond what
we currently do, with or without David's patch. Who knows, you might even
prove my theory that it won't show a measurable different wrong :-)
jeff
More information about the Gcc
mailing list