SEQUENCEs

[law at redhat dot com]

I've been loosely monitoring the discussion between Dave and Joern and
was disappointed to see Dave abandon his patch due to Joern's objections.
This morning, I went back and reviewed the thread in more detail.  If I get
anything wrong, please let me know.

Dave's patch clearly improves the amount of RTL we generate.   On
hppa2.0-hp-hpux11.00 Dave's shows a reduction of 2% in the amount of RTL
objects we generate (using my 162 tests) and shows a small (.4%) but
consistent improvement in compile times.  Results on i686-pc-linux-gnu are
basically the same.

In addition to the improvements in compile times and RTL object creation, I
think the patch also simplifies the compiler, which is good.

--

The only objection to the patch was from Joern and it appears to be centered
around the lack of a way to splice in chains of RTL cheaply because we no
longer have a pointer to the end of the chain of RTL.

A valid point, but hardly something that should cause us to abandon David's
patch -- particularly when one considers that even though this pointer existed
in the SEQUENCE, we didn't actually use it to do low cost insertions!

If Joern (or anyone) wants to improve how we splice a chain of insns into 
another
chain of insns, then I encourage them to do so.  However, that can and should
be done independently of David's patch.   The fact that it'll be modifying the
same areas of the compiler that David's patch modifies shouldn't cause us
to abandon David's patch.

And just for fun, I instrumented GCC to keep track of the kinds of sequences
it creates.  For a bootstrap of i686-pc-linux-gnu, I simply recorded the length
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
need to do so.  In fact, the data is skewed so heavily to the 1 insn sequence
that I'd be rather surprised if improving the insertion of multi-insn sequences
would have any measurable impact on the compiler.  If we do find in the future
that this is a problem, we can certainly address it.

I believe David bootstrapped and regression tested the patch on sparc-*-linux;
I've also bootstrapped and regression tested the patch on i686-pc-linux-gnu
as well as hppa2.0w-hp-hpux11.00.

--

I believe Richard pointed out a problem with the Alpha where David's patches
would break things, particularly dealing with setjmp/longjmp calls.  Richard,
can you rewrite the code in question?  I could try, but I'd probably get it
wrong :-)


jeff