This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Reload problem
> 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.
Yes, the code is already barely understandable. But at least, up to now, all
conditions appear to be verifiable a priori.
> 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.
It is my understanding that recognizing insns is an expensive process, so I
think that adding it to push_reload would be the last resort solution.
But, more fundamentally, I think that we abuse push_reload by calling it on
(plus:SI (reg:SI 1 r1 [174])
(const_int 128 [0x80]))
because we implicitly ask it to do two reloads in a row, while it is only
wired to do one. So it implicitly relies on gen_reload to do the second one,
but this is IMHO more a hack than a feature.
> 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.
I think that fixing find_reloads_address_part would be the cleanest solution
and, again, that an a priori solution would be better than the recog stuff.
Could we extend the scope of the LEGITIMATE_CONSTANT_P macro, by adding a
second argument PLUS_CLASS that would be specified as follows:
- if PLUS_CLASS == NO_REGS, returns 1 if the constant is valid as an
immediate operand in a SET,
- if PLUS_CLASS != NO_REGS, returns 1 if the constant is valid as an
immediate operand in a PLUS with a register of class PLUS_CLASS?
All calls to find_reloads_address_part are performed either on a constant or
on a PLUS with a base hard reg and a constant so we could add a new
parameter PLUS_CLASS to the function.
Thanks for your help in clearing up this problem.
--
Eric Botcazou