This is the mail archive of the gcc-patches@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: [RFC] Kill gen_sequence


On Thu, 6 Jun 2002, Geoff Keating wrote:

> > Date: Thu, 6 Jun 2002 16:48:18 -0400
> > Cc: davem@redhat.com, gcc-patches@gcc.gnu.org
> > From: Daniel Berlin <dberlin@dberlin.org>
> > X-Spam-Status: No, hits=-1.8 required=5.0 tests=IN_REP_TO,NO_MX_FOR_FROM,AWL version=2.20
> > 
> > 
> > On Thursday, June 6, 2002, at 04:01  PM, Geoff Keating wrote:
> > 
> > >> Date: Thu, 6 Jun 2002 15:56:17 -0400
> > >> Cc: "David S. Miller" <davem@redhat.com>, gcc-patches@gcc.gnu.org
> > >> From: Daniel Berlin <dberlin@dberlin.org>
> > >
> > >> But as he points out, its only using sequences insofar as it's translating sequences into SSA form, and for some subreg cases.
> > >>
> > >> IE it transforms (set (subreg (reg foo)) ...)
> > >> into
> > >> (sequence [(set (reg foo_1) (reg foo))
> > >>             (set (subreg (reg foo_1)) ...)])
> > >>
> > >> The sequence is not necessary here however, at least, it shouldn't be.
> > >
> > > Why not?  You clearly can't substitute a PARALLEL for it.
> > I didn't say you should, even though you could.
> > You aren't thinking about SSA's properties, you are think of what parallels do for code generation.
> > Remember the single assignment property. Then look again at the
> sequence (which is just a bunch of unsplit insns), and tell me how we
> are satisfying that property.
> 
> Look again.  These SEQUENCEs don't contain insns, they contains plain
> RTL, just like a PARALLEL doesn't contain insns.

Um.
"
@findex sequence
@item (sequence [@var{insns} @dots{}])
Represents a sequence of insns.  Each of the @var{insns} that appears
in the vector is suitable for appearing in the chain of insns, so it
must be an @code{insn}, @code{jump_insn}, @code{call_insn},
@code{code_label}, @code{barrier} or @code{note}.

A @code{sequence} RTX is never placed in an actual insn during RTL
generation.  It represents the sequence of insns that result from a
@code{define_expand} @emph{before} those insns are passed to
@code{emit_insn} to insert them in the chain of insns.  When actually
inserted, the individual sub-insns are separated out and the
@code{sequence} is forgotten.
"

So we are abusing sequences for SSA.
I haven't looked at the RTL SSA dumps in a while, so if this is correct, 
then just ignore the rest.

--Dan


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