This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA:] Fix PR target/{18329,18330}, incorrect deletion of output-reload

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]