Re: sched-ebb.c bug (was Re: [3.3 branch] IA64 bootstrap failure)

[Jakub Jelinek <jakub at redhat dot com>]

On Wed, Jul 09, 2003 at 10:35:02PM -0700, Jim Wilson wrote:
> 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
> works. 
> 
> 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. 

On 64-bit hosts we have there 32 bits left, so that could be used as flags.
Unfortunately, on 32-bit hosts there are no bits left and it doesn't look
like we can reuse any of the fields easily, maybe trim hash value to 31 bits
and make value a bitfield, but I don't think that's a good idea. 

> 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. 

That looks very expensive.

	Jakub