This is the mail archive of the gcc-patches@gcc.gnu.org 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: [PATCH]: Fix PR c/12372


> On Fri, 10 Oct 2003 16:24:17 -0700, Richard Henderson <rth@redhat.com> wrote:
> 
> > On Fri, Oct 10, 2003 at 03:20:50PM -0400, Jason Merrill wrote:
> >> Then perhaps affected functions should be downgraded to pure.
> >
> > I don't agree.  That has much more wide-ranging affects.
> 
> How so?  The difference between pure and const calls is that pure calls use
> memory and const calls don't.  This patch erases that distinction.  There's
> already code in calls.c that does what I was suggesting for
> pass-by-invisible-reference args:
> 
>           /* If this was a CONST function, it is now PURE since
>              it now reads memory.  */
>           if (flags & ECF_CONST)
>             { 
>               flags &= ~ECF_CONST;
>               flags |= ECF_PURE;
>             }
> 
> This seems like an analogous situation.

Yes, except that this code has no effect.  The immediately preceding
line is

          flags &= ~(ECF_CONST | ECF_PURE | ECF_LIBCALL_BLOCK);

I don't understand why other ports are not affected by this problem.  On
the i386, there is a clobber of memory prior to the tail call:

(insn 72 71 73 0 (parallel [
            (set (reg/f:SI 7 esp)
		(plus:SI (reg/f:SI 6 ebp)
		    (const_int 0 [0x0])))
	    (clobber (reg:CC 17 flags))
	    (clobber (mem:BLK (scratch) [0 A8]))
	]) -1 (nil)
    (expr_list:REG_UNUSED (reg:CC 17 flags)
	(nil)))

which may keep the args from being deleted.  In any event, it would seem
that the clobber will eliminate the distinction between const and pure
for the following tail call.  We could generate a similar clobber
on the pa at the stack adjust but is this the right thing to do?

I tend to think that in distinguishing const and pure functions, memory
accesses to the argument block shouldn't be a determining factor.  Thus,
it would seem better to find some other way to keep the arguments of a
const sibcall from deleted by flow.  For non-sibcalls, the parameters
are enclosed in LIBCALL...RETVAL notes preventing the individual stores
from being considered separately for deletion.


Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)


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