This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: SEQUENCEs
- From: law at redhat dot com
- To: Joern Rennecke <joern dot rennecke at superh dot com>
- Cc: Marc Espie <espie at quatramaran dot ens dot fr>, gcc at gcc dot gnu dot org
- Date: Tue, 11 Jun 2002 08:03:55 -0600
- Subject: Re: SEQUENCEs
- Reply-to: law at redhat dot com
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