This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Reload problem
- From: Jim Wilson <wilson at specifixinc dot com>
- To: Eric Botcazou <ebotcazou at libertysurf dot fr>
- Cc: gcc at gcc dot gnu dot org
- Date: Wed, 10 Sep 2003 15:59:22 -0700
- Subject: Re: Reload problem
- References: <200309092248.50884.ebotcazou@libertysurf.fr>
Eric Botcazou wrote:
- gen_reload expects a three operands expression but it is short-circuited by
push_reload
I think the code in push_reload is primarily at fault here. This is an
optimization trying to reduce the number of spill registers, but it is
very tricky to get right. We've already had a number of problems with
this code before, and it has a growing list of conditions that must be
met before we use it.
I think someone (maybe Joern?) once proposed modifying this code to emit
a test reload and try to recognize it. If this fails, then we can't use
the dying register as the spill register. This would mean doing some of
the stuff gen_reload does, e.g. call emit_insn, recog_memoized,
extract_insn, and constrain_operands. And only if all of these succeed
is it safe to use the dying register as the spill register.
It seems like we shouldn't have to do all of that work, but I don't see
any other way to fix it in push_reload.
Fixing find_reloads_address_part sounds reasonable also. However, the
only way to see if the PLUS operands are valid is to do the same thing I
mentioned above, e.g. emit an instruction and see if it can be
recognized and if the operands match the constraints. Since we have
less info here (i.e. we don't have the reload register which is the
destination register for the insn), this is less likely to be completely
safe.
Since we are making essentially the same fix in one of two places, we
should consider some other issues, such as which place is least
frequently executed (and thus has the least affect on compiler runtime),
and which place gives the best resulting code.
I guessing that push_reloads wins, but I can't be certain.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com