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: More info on gcc 3.3 ia64 bootstrap comparison failure

On Tue, 2003-07-15 at 11:08, H. J. Lu wrote:
> cselib_subst_to_values is called 3 times in sched-deps.c. 2 of them
> call cselib_lookup first. What is the purpose of calling cselib_lookup?

Internal to cselib, it creates a VALUE rtx, sets its value to the input
RTL, and sets up the data structures that are used to track uses of the
VALUE rtx, so that we can tell when they are still in use.  External to
cselib, it isn't doing much useful, especially considering the fact that
we aren't using the return value from it.  The tracking code is of no
use here because it can't track references outside of cselib.  This is
the real problem here.

> Is that to tell cselib that it is used? However, add_insn_mem_dependence
> doesn't call cselib_lookup. I added
> 	cselib_lookup (XEXP (mem, 0), Pmode, 1);
> to add_insn_mem_dependence. It doesn't solve the problem. On

It appears to me that the code in add_insn_mem_dependence is
superfluous.  There are only two places that call
add_insn_mem_dependence, and both of them call cselib_subst_to_values
before calling add_insn_mem_dependence, so the call inside that function
doesn't appear to be doing anything.  Oh wait, I see that we pass the
original MEM to add_insn_mem_dependence instead of the modified one, and
then we modify it again inside add_insn_mem_dependence.  That doesn't
make any sense.  Also, add_insn_mem_dependence should be static, and
should have its prototype removed from sched-int.h.

> 1. Should the POST_INC case be handled in add_insn_mem_dependence?

I think all VALUE rtx used because of cselib_subst_to_value are in
danger of becoming dangling pointers.  There is nothing special about
POST_INC here.

> 2. Is cselib_lookup needed in add_insn_mem_dependence?

I think the cselib_lookup call is unnecessary, because it will have
already been called once before we reach here.  But then, I think this
entire code here is unnecessary, since the caller could have passed in
the modified MEM to begin with.

> 3. If yes, what should add_insn_mem_dependence do when cselib_lookup
> returns NULL?

Maybe that is why we aren't using the cselib_lookup return value
directly, because it sometimes return NULL.  cselib_subst_to_value
doesn't have this problem, it always returns usable rtl.

I think we either need to stop calling cselib_subst_to_value for MEMs
added to dependence lists, or else we need to add callbacks into cselib
to indicate which values are used outside cselib so that we can preserve
them until they are no longer used.
Jim Wilson, GNU Tools Support,

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