This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Potential bug in stmt.c (expand_value_return)
- To: Richard Henderson <rth at cygnus dot com>
- Subject: Re: Potential bug in stmt.c (expand_value_return)
- From: Joern Rennecke <amylaar at cygnus dot co dot uk>
- Date: Wed, 2 Feb 2000 22:30:51 +0000 (GMT)
- CC: Joern Rennecke <amylaar at pasanda dot cygnus dot co dot uk>, Denis Chertykov <denisc at overta dot ru>, gcc at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org
> No, it wasn't accidental. The information is available instead
> from EXIT_BLOCK_PTR->global_live_at_start.
That's not a conventient place when you are looking at a sucesion of insns
with a recursive function that gets passed just the piece of rtl.
> What optimizations need the actual use insn?
I can't search through the whole compiler now, but I know that
reload_combine needs it, and the register scavenging for out-of
range branchs on the sh (config/sh/sh.c:gen_block_redirect).
USEs are also much easier to digest for peepholes than looking into
a global array when you hit a return insn.