This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Tree-SSA self checking infrastructure
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Jan Hubicka <jh at suse dot cz>, Jan Hubicka <hubicka at ucw dot cz>, gcc mailing list <gcc at gcc dot gnu dot org>
- Date: 19 Nov 2003 16:45:27 -0500
- Subject: Re: Tree-SSA self checking infrastructure
- References: <200311192129.hAJLT905012019@speedy.slc.redhat.com>
On Wed, 2003-11-19 at 16:29, law@redhat.com wrote:
> In message <20031119205044.GL11681@kam.mff.cuni.cz>, Jan Hubicka writes:
> >> In message <20031119203450.GS16923@atrey.karlin.mff.cuni.cz>, Jan Hubicka w
> >rite
> >> s:
> >> >> In message <20031119190649.GQ16923@atrey.karlin.mff.cuni.cz>, Jan Hubic
> >ka w
> >> >rite
> >> >> s:
> >> >> >This brings me into questions about my tail call updating code.
> >> >> >Perhaps I need to re-do SSA form on call cobbered variables after
> >> >> >removing the call?
> >> >> Are you changing the CFG? Are you changing the dominator tree? Those
> >> >I replace tail call by edge back to the beggining of function and I
> >> >possibly split edge fron entry point. I also take care to construct PHI
> >> >nodes for all referenced arguments by hand.
> >> >This does change CFG, but does not change dominance relationships.
> >> >I am however removing call and perhaps we are maintaining something that
> >> >relies on the presence of call...
> >> Since you're not changing the dominance relationships, I think you are
> >> safe. Presumably you create a PHI node for every variable that is set
> >> inside the newly created loop which is also live at the head of the loop.
> >> Right?
> >Hmm, well, does the case of uninitialized variables count? Can I detect
> >these somehow?
> Yes, I think they do. This has always been a little fuzzy to me, but
> I believe folks have argued that you want a PHI if there is a join point
> where the uninitialized version meets with some initialized version.
>
> jeffa
>
An SSA version which is uninitialized (apparently there can be only one)
for any given variable can be found via:
d = default_def (var);
So if the default definition of a variable is an empty stmt, that means
it has no DEF.
so...
if (EMPTY_STMT_P (SSA_NAME_DEF_STMT (ssa_name))
{
/* This means there is no definition of ssa_var */
if (default_def (SSA_NAME_VAR (ssa_name)) == ssa_name)
{
/* This is the uninitialized ssa version for the variable.*/
}
else
{
/* This is an error condition. This is not the default
definintion, nor is it defined. */
}
}
I thinki its owrks that way. That shjow we check in live_on_entry in
tree-ssa-live.c
If you dont like it, talk to Diego, thats the way he implelemted it
after I pestered him for a long time in order to be able to detect these
:-)
Andrew