This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: 19991023 ICE compiling XFree86
- To: Richard Henderson <rth at cygnus dot com>
- Subject: Re: 19991023 ICE compiling XFree86
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Tue, 26 Oct 1999 22:18:47 -0600
- cc: Alan Modra <alan at SPRI dot Levels dot UniSA dot Edu dot Au>, gcc-bugs at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
- Reply-To: law at cygnus dot com
In message <19991026211023.A20666@cygnus.com>you write:
> > I believe that was the whole point behind the unusual definition of
> > find_basic_block (I'm guessing this originally came from reorg.c).
>
> Yeah it did. I can't imagine how it used to work though. The
> incorrect answer I was seeing wasn't even vaugely close.
>
> So, like, what does reorg need this resource stuff for if it
> doesn't have to be right? Does it get some indication that the
> data isn't valid and just gives up? I guess some study is in
> order....
It needs to track what registers are live on both paths of conditional jumps
so that it knows what insns are always safe to put in a delay slot or
what insns are safe to put in an annul-true or annul-false slot.
If it gets too confused it is supposed to give up and assume the worst.
It's always been some of the worst code in reorg/resource.
I actually looked at replacing cross-jump completely with something similar
to code hoisting. The basic ideas are the same, except that we move stuff down
in the cfg to post dominators. Anyway, I never got around to working through
all the details (it's assignment motion and needs to deal with hard regs too).
jeff