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


On Tue, Mar 4, 2008 at 8:47 PM, Richard Sandiford
<rsandifo@nildram.co.uk> wrote:
> "Steven Bosscher" <stevenb.gcc@gmail.com> writes:
>  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.

Yes, for hard registers you can't use this. Another example is the
loop counter register on ia64, or the flags register on i386.

You should have a look at the history of RTL SSA for hard registers
(http://gcc.gnu.org/ml/gcc-patches/2000-07/msg01285.html and thread).
They used to put selected hard regs into SSA form. Lessons learned:
don't do that.  I think the same applies to FUD chains for hard
registers.


>  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.

Uh, hard registers *are* special.  And, also quite important, what
would you *do* with FUD chains for hard registers?  We don't optimize
many things with hard registers, usually just because it's harder to
do than for pseudos.  I don't think FUD chains would change that.

>  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?

Old RTL SSA did (a).  It didn't work.  Neither (b) nor (c) seem viable
ideas to me...

Gr.
Steven


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