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: Marc Espie <espie at quatramaran dot ens dot fr>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 10 Jun 2002 21:46:35 -0600
- Subject: Re: SEQUENCEs
- Reply-to: law at redhat dot com
In message <200206110235.g5B2ZEZ04440@quatramaran.ens.fr>, Marc Espie writes:
> In article <6491.1023755308@porcupine.cygnus.com> you write:
> >And just for fun, I instrumented GCC to keep track of the kinds of sequence
> s
> >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
>
> Hum... how are such sequences then used ?
The vast majority of the time you simply insert them at some point in the
existing insn chain.
> Would it make sense to try to optimize the most common case further (1 insn)
> or maybe the two most common cases (<=2, 90%) ?
It's unclear at this point. I could speculate that there might be more we
can do for the 1 insn case, but one of the things that naturally falls out
of David's patches is streamlining of the 1 insn case. Beyond that I'm not
sure how much else can really be improved for that case.
I thought briefly about how to optimize for the 2 insn case, but it's
really no different than the 3, 4 or 5 insn case, except that the list you
have to traverse to get the last insn (those few times you actually need it)
is smaller.
jeff