[tree-ssa] Operand management II

[Jan Hubicka]

> In message <1071610959.13039.192.camel@p4>, Andrew MacLeod writes:
>  >Now, I've discovered something very interesting along the way. The SSA
>  >verifier is not catching all the problems we have. In fact, when I first
>  >enabled this, I had 45 more failures in the gcc testsuite, all due to
>  >the verifier.
>  >
>  >It turns out that an optimization can do something incorrect, like
>  >remove a VDEF which still has uses, and the verifier may not catch it
>  >because when it looks at SSA_NAE_DEF_STMT(ssa_name), it still points to
>  >the old VDEF which was deleted.  AS long as that memory hasn't been
>  >stomped on, it still looks fine. Ahhhh. So what was happening, I was
>  >freeing an operand, overwriting the first word to use as a 'next'
>  >pointer, and voila, it triggers the ssa verifier since it is no longer
>  >correct.
> FWIW, Jan has some improvements to the verification code which may 
> (or may not) help detect this stuff.

I don't detect this directly now.  But if there is "released" bit
somewhere in the datstructure, like SSA_NAMEs, it is all easy - all you
need is to check that the bit is not set during checking.  verify_ssa is
convenient place for this.  Alternate plan is to do ENABLE_CHECKING
memset in the "free" call.
> 
> I'm still trying to figure out how I want to twiddle the SSA_NAME recycling
> code to make it more robust in terms of not leaving dangling SSA_NAMEs
> in the IL.

This is done currently by the verify_stmt patch you checked in.  Only
limitation can be that we do verify_stmt just twice during compilation
queue.  I am working on making verify_stmt more usefull by adding gimple
grammar checking and such, so it would be nice to have it run in between
each pass.

I also introduced new timevars for checking code.  verify_ssa currently
run as often and consume about 6% of compilation time most of time was spent
in get_smtmt_operands last time I checked, so accounting is not very
fair as the stmt_operands would get updated lazilly later anyway.
For large functions calculate_value also may become an issue, but hope
Zdenek will solve this one.

verify_stmts is cheaper.  Even with gimple grammar checker I was getting
about 3% of compilation time (currently it is 1%).  Whether this is
acceptable for default settings or not is a question.  Of course
checking code is usefull only when time it saves in bughunting is
smaller than time it burn by waiting for bootstraps to finish.

Honza
> 
> 
> Jeff