[vta, vta4.4] merged with trunk and 4.4 @149247, updated VTA patchset

Alexandre Oliva aoliva@redhat.com
Sun Jul 12 07:11:00 GMT 2009


On Jul  7, 2009, Richard Henderson <rth@redhat.com> wrote:

> On 07/07/2009 01:17 PM, Alexandre Oliva wrote:
>> On Jul  7, 2009, Richard Guenther<richard.guenther@gmail.com>  wrote:
>>> Ok, so I retract the lazy updating theory (I thought it would get rid
>>> of the move/remove functions).  Doing lazy updating during checking
>>> may introduce code generation differences with checking enabled/disabled
>>> (you shouldn't be changing IL during checking really).

> Definitely no code changes during verification.

So...  I found out that the verification failures had to do with an
overconservative decision I'd made in maybe_replace_use_in_debug_stmt():
to keep a non-current SSA_NAME in place if there wasn't a current
definition yet.

Turns out that decision was never correct.  In some such cases, we must
fallback to the default definition, if there is one.  In others, we'd
have had to create a new PHI node in order to have some SSA-valid name
to refer to.

Problem is, I haven't been able to figure out how to decide at that
point whether to use a default value, if there is one, or drop the debug
expression.  ATM (in the patch I'll post soon) I'm only retaining
default definitions when they were already there, but I'm pretty sure
this drops debug info unnecessarily, and I'm a bit concerned it might
not be right in other cases, although I can't think of any example.
Suggestions?


Anyhow...  With this, I could do away with check_and_update_debug_stmt()
&Co, so now all we have is propagate_*_into_debug_stmts(), called from
release_ssa_name() and a few other places.

No lazy updating, no invalid SSA, no changes during verification.  Yay!

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer



More information about the Gcc-patches mailing list