Re: [tree-ssa] Fix mudflap codegen and allow optimizations [patch]

[Diego Novillo <dnovillo at redhat dot com>]

On Sun, 2003-04-27 at 20:12, Jason Merrill wrote:
> On Sun, 27 Apr 2003 18:02:36 -0400, Diego Novillo <dnovillo at redhat dot com> wrote:
> 
> > Finally, I moved mudflap to run after the SSA optimizers.
> 
> This seems wrong to me.  mudflap seems like the sort of local
> transformation that should happen early, much like inlining, so that the
> transformed code is exposed to the other optimization passes.
> 
I forgot to talk about the long-term plan for mudflap.  Currently,
mudflap is a monolithic pass where the decision to instrument and the
instrumentation itself are done in one shot.  Furthermore, as you can
see from the code I showed in my original message, the instrumentation
is *extremely* heavy and intrusive.  Each array/pointer reference
creates a new sub-graph complete with a table lookup and a function
call.  That shatters basic blocks and the function call creates more
chances for the optimizers to get confused by clobbering.

Mudflap benefits from anything that will reduce the number of
pointer/array dereferences at runtime.  Any scalarization and code
hoisting pass that runs before mudflap will help it by not giving
mudflap a chance to instrument.  Also, there are mudflap-specific
optimizations that Frank has suggested.  For instance,

	p->a =
	p->b =
	p->c =

Instead of inserting three mudflap checks for each offset into 'p', we
insert only one before p->a with enough extent to cover the three
fields.

So, if mudflap drops a sub-graph for every pointer dereference it wants
to instrument, it creates a lot of unnecessary work for the optimizers
and it will very easily confuse them.  Point in fact, the deadcode that
we could remove before mudflap is never removed if we allow mudflap to
instrument first.

Instead, mudflap should generate a new GIMPLE code that encapsulates the
check.  Something like TREE_MUDFLAP <pointer, extent>.  This is taken by
the optimizers as another GIMPLE statement, you don't break basic blocks
and avoid confusing the optimizers.

That would move mudflap somewhere in the middle of the SSA optimization
chain.  Once we add it there, we can start thinking about mudflap
specific optimizations (done after/while mudflap) or preemptive passes
that help mudflap by exposing fewer pointer/arrays to it.

So, moving mudflap at the end of the SSA chain is just a stop-gap
measure until we incorporate mudflap into the process.


> > Although the optimizers are still not very smart wrt pointers and
> > arrays, they do manage to remove the odd pointer or array
> > reference.  And, in fact, after I did that a bunch of libmudflap
> > tests started failing because DCE was removing the very code that
> > mudflap was supposed to instrument.
> 
> ??? If the accesses were dead, then DCE should remove them.  Sounds like we
> want to fix the testcases, not cripple the optimizers.
> 
Check the patch.  That's what I did.  I fixed the testcases.  I didn't
cripple the optimizers.

The tests are overly simplistic and are designed to trigger mudflap's
runtime in very obvious ways:

int main ()
{
int foo [10];
foo[10] = 0;
return 0;
}

Yes, the whole function is dead.  Other than rewriting the testcase into
something not obviously dead, I took the path of least resistance and
declared 'foo' volatile.


Diego.