birthpoints in rtl.

[Kenneth Zadeck]

Richard Sandiford wrote:
> "Steven Bosscher" <stevenb.gcc@gmail.com> 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.

kenny