This is the mail archive of the 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: birthpoints in rtl.

Richard Sandiford wrote:
> "Steven Bosscher" <> writes:
>> For the location of the extra instructions, I would *not* keep them on
>> the side.  If you have something special going on, my motto is: "Make
>> it explicit".
> Going back to something discussed upthread: would you expect to use this
> for hard regs as well as pseudos?  No-op moves aren't necessarily supported
> for all hard registers.  E.g. MIPS doesn't have patterns for LO <- LO,
> even though LO is a normal non-fixed register.  You can also have hard
> registers that only appear in fixed patterns, such as condition code REGs.
> If we went for an explicit move, I assume we would either have to
> (a) discount hard regs that can't be moved, (b) force backends to
> allow all no-op moves or (c) circumvent the backend somehow.
> (Jan suggested a USE for (c), but I assume we'd want some sort
> of definition too.)
> Kenny said that pseudos-only was better than nothing, and I can't
> disagree with that.  But one of the nice things about the on-the-side
> idea is that you have none of these problems.  There should be nothing
> special about hard regs.
> I take your point about not wanting something special going on behind
> the scenes.  But these insns seem pretty special in their own right,
> especially if we go for (a) or (c).  Even if we go for (b), wouldn't
> optimisers need to know that they shouldn't just delete the moves?
> Richard
This is the first concrete argument that i have seen for keeping them on
the side.  The rest of the discussions (including my own) have been
mostly beauty as opposed to truth.

>From my point of view, this is a killer argument that if we want to
build fuds/birthpoints for all regs, the info must be on the side.

I want to build the info for everything because i want to ditch the
reaching defs way of building chains in favor of building them using the
existing ssa technology.   I do not want to have to call both techniques
to build the chains.


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