This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: birthpoints in rtl.
- From: Kenneth Zadeck <zadeck at naturalbridge dot com>
- To: Steven Bosscher <stevenb dot gcc at gmail dot com>, Jan Hubicka <hubicka at ucw dot cz>, Kenneth Zadeck <zadeck at naturalbridge dot com>, Diego Novillo <dnovillo at google dot com>, gcc <gcc at gcc dot gnu dot org>, "Bonzini\, Paolo" <bonzini at gnu dot org>, "Park\, Seongbae" <seongbae dot park at gmail dot com>, Ian Lance Taylor <iant at google dot com>, rsandifo at nildram dot co dot uk
- Date: Tue, 04 Mar 2008 14:55:22 -0500
- Subject: Re: birthpoints in rtl.
- References: <47C5EF2A.5020401@naturalbridge.com> <47C6B132.3090903@naturalbridge.com> <47C88C6B.8030809@google.com> <571f6b510802291604t6ba0d302uc1a6bda69a7f807@mail.gmail.com> <47C89EC3.7030109@google.com> <47C8B3BB.4000801@naturalbridge.com> <20080301101315.GB24550@atrey.karlin.mff.cuni.cz> <571f6b510803041108i3fa5aa7fw61bccb913a996b03@mail.gmail.com> <87fxv6l19d.fsf@firetop.home>
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