[PATCH] Fix PR 18746, fab causing more problems

[Diego Novillo]

On Wed, Dec 01, 2004 at 09:37:55AM -0800, Richard Henderson wrote:
> On Tue, Nov 30, 2004 at 10:00:13PM -0500, Andrew Pinski wrote:
> > -	  modify_stmt (*stmtp);
> > +	  mark_new_vars_to_rename (*stmtp, vars_to_rename);
> 
> Why isn't this redundant with the mark_new_vars_to_rename call
> in convert_to_gimple_builtin?
> 
It's never invoked,  We are replacing strcpy with
__builtin_memcpy, which is a valid GIMPLE result in this context,
so convert_to_gimple_builtin is not necessary.

What's happening here is the following:

After FAB, we leave the statement in a "modified" state, so
the next time we call get_stmt_operands, it will be rescanned
from scratch.

It so happens that with the verifier disabled, the next time we
call get_stmt_operands on __builtin_memcpy is in the alias
analyzer itself.

At this point, the alias analyzer is rebuilding alias sets, so
all pointers have their points-to sets and type tags have their
aliases sets cleared.  So, TMT.0 (which ends up aliased to 'buf')
is at this point not related to 'buf'.  So, it ends up in the
list of V_MAY_DEFs, completely unexpected.

So, the call to mark_new_vars_to_rename actually prevents the
alias analyzer from tripping itself over incomplete alias info.

This is not the ideal solution, but is the least intrusive I can
think of. Ideally, we could probably have a flag for
get_stmt_operands to only do real operands.  Or, the alias
analyzer could do a prior pass of refreshing statement operands
before it clears all the alias sets.

Other suggestions?


Diego.