This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: SEQUENCEs


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]