This is the mail archive of the
mailing list for the GCC project.
Re: Fix for reload-failure
- From: Michael Matz <matz at suse dot de>
- To: Geoff Keating <geoffk at geoffk dot org>
- Cc: <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 7 Feb 2003 23:46:13 +0100 (CET)
- Subject: Re: Fix for reload-failure
On 7 Feb 2003, Geoff Keating wrote:
> > Now, when the actual insns for the reloads are emitted, some subfunctions
> > of emit_move_insn() (in particular legitimize_pic_address() in i386.c)
> > notices, that the address of the constant "(symbol_ref/u:SI ("*.LC0"))" is
> > not actually a valid PIC address, so it makes it simply valid, and because
> > it's written in the way it is, it also changes regs_ever_live for the
> > PIC-reg (which now indeed is required) to 1.
> This is the problem. If the address isn't a legitimate address, reload
> should have noticed this earlier,
I agree, but that's not easily possible. Because there are
target-dependent ways to make an address legitimate for PIC, and some of
them involve to emit code. As far as reload is concerned the address from
force_const_mem() is a valid address (and it actually is, if flag_pic
weren't set). The address is only created during collecting reloads, so
it can't be validized before. And during collecting reloads, there shall
be no changes in the code. And validizing a PIC address isn't always
possible with reloads. For instance for this case the address first is:
to validize that for PIC it needs to be changed into:
(plus:SI (reg:SI 3 ebx)
(const:SI (unspec:SI [
There simply _is_ no reload which does something like that, so if the
first address weren't valid for reload it would do strange and funny
things while trying to make it valid (because it's just a symref it can't
really split it more, loading it into a reg doesn't make it go away, so
_somewhere_ the symref would remain, and then while emitting the reloads,
the same would happen as now).
But we can simulate the _effect_ of validating it. As far as reload is
concerned the difference beween both addresses is, that the latter form
needs %ebx live (they are both valid addresses).
> not when it goes to actually emit the instructions, and generated
> reloads for it then, which should have involved the PIC register.