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: sched-ebb.c bug (was Re: [3.3 branch] IA64 bootstrap failure)

On Wed, 2003-07-09 at 16:35, Jakub Jelinek wrote: 
> Maybe add a flag to cselib, such that remove_useless_values is never called
> from cselib_process_insn if called from sched-deps.c.
I haven't looked at cselib before, so I don't know too much about how it

It does look like there is a modularity violation here.  The value RTL
was originally designed to be local to the cselib module.  Then later a
cselib_subst_to_values call was added into sched-deps, and now there are
value RTL objects outside cselib that aren't being tracked.  These turn
into dangling pointers when cselib frees up unused values, and then we
get problems when we dereference the dangling pointers. 

Since we have to call cselib_init before using cselib_subst_to_values,
we could perhaps pass an extra argument to cselib_init to solve the
problem.  Telling it not to free apparently unused value objects would
be easy, but will increase memory usage by an unknown amount. 

Another alternative here is to change the sched-deps.c calls to
cselib_subst_to_values.  We could rename this function to
cselib_subst_to_values_1, and then add a cselib_subst_to_values function
that marks the value somehow so that cselib knows that it can't delete
it even if it appears to be unused.  We could maybe reuse an existing
field, but it isn't clear if we can safely use any of them.  We might
have to add an extra field, and that will increase memory usage. 

Another possibility would be to add a callback.  We can pass a callback
as an argument to cselib_init.  Then in discard_useless values, if there
is a callback, we call it before deciding whether a value is unused. 
This looks potentially inefficient though, since we would have to scan
the entire deps list each time the callback is called, so I think this
is the worst solution of the bunch. 


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