This is the mail archive of the
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.email@example.com> <47C6B132.firstname.lastname@example.org> <47C88C6B.email@example.com> <firstname.lastname@example.org> <47C89EC3.email@example.com> <47C8B3BB.firstname.lastname@example.org> <20080301101315.GB24550@atrey.karlin.mff.cuni.cz> <email@example.com> <firstname.lastname@example.org>
Richard Sandiford wrote:
> "Steven Bosscher" <email@example.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?
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.