This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [RFA:] Fix PR target/{18329,18330}, incorrect deletion of output-reload
- From: Richard Henderson <rth at redhat dot com>
- To: Hans-Peter Nilsson <hp at bitrange dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 10 Jan 2005 23:48:07 -0800
- Subject: Re: [RFA:] Fix PR target/{18329,18330}, incorrect deletion of output-reload
- References: <Pine.BSF.4.58.0501091022420.22403@dair.pair.com>
On Sun, Jan 09, 2005 at 10:26:01AM -0500, Hans-Peter Nilsson wrote:
> (call_insn 25 24 54
...
> (insn 26 54 60 1 (set (reg:DI 259 rJ) (reg:DI 278))
...
> (barrier 61 60 29)
...
> (code_label/s 29 61 36 2 3 "" [1 uses])
...
> (insn 34 33 35 2 (set (reg:DI 259 rJ) (reg:DI 278))
...
> In global allocation, pseudo 278 gets allocated a stack slot, but as
> memory is not valid for move to the return-address-register rJ, it is
> reloaded into register 2, which happens to be valid and live unto the
> death of pseudo 278 on the "straight" execution path.
Is r2 call saved? It's not usual to pick call-saved registers for
reload registers, so something seems fishy to begin with.
If it is call saved, then this could be valid in the non-exception
case. Which leads to ...
> If non-call-exceptions should be covered as well
> (nonlocal-goto and calls should cover "normal C++" call-exceptions)...
Yes, non-call exceptions would be a problem. As would normal exceptions,
which your test:
> + if (CALL_P (i1) && current_function_has_nonlocal_label)
does *not* handle. What ought to be happening is that all of this
deletion nonsense needs to be cropped across basic block boundaries.
We should be able to notice those, at least.
r~