This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc/resource.c mark_target_live_regs Question
- To: Jeffrey A Law <law at redhat dot com>
- Subject: Re: gcc/resource.c mark_target_live_regs Question
- From: Jeffrey Oldham <oldham at codesourcery dot com>
- Date: Thu, 15 Feb 2001 08:07:30 -0800
- Cc: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>, rth at redhat dot com, gcc at gcc dot gnu dot org, Jeffrey Oldham <oldham at codesourcery dot com>
- Organization: CodeSourcery LLC
- References: <2022.982209415@slagheap.cygnus.com>
Jeffrey D. Oldham wrote:
> Why does resource.c's mark_target_live_regs() start computing live
> registers at the previous BARRIER rather than the beginning of the
> basic block containing the target? For functions with lots of
> instructions but few BARRIERs, this can lead to O(n^2) performance
> even if the function has many basic blocks.
The consensus answer seems to be:
On Wed, Feb 14, 2001 at 08:56:55PM -0700, Jeffrey A Law wrote:
>
> In message <10102150239.AA27811@vlsi1.ultra.nyu.edu>you write:
> > It is accurate now. But as I mentioned elsewhere, reorg
> > destroys the cfg, so it doesn't matter.
> >
> rth is right. reorg completely scroggs the cfg.
If it is completely "scrogg"ed, why can
gcc/resource.c:mark_target_live_regs(), line 961, use the live
register information? Is live register information for blocks
beginning immediately after barriers preserved while other live
register information is unreliable?
Thanks for the information,
Jeffrey D. Oldham
oldham@codesourcery.com