Re: [tree-ssa] Avoid nondeterminism in tree-ssanames

[Jan Hubicka <jh at suse dot cz>]

> > Jan Hubicka <jh@suse.cz> writes:
> > 
> > > Hi,
> > > I've run into problem that tree-ssanames in combination with garbage
> > > collector may produce non-deterministic results.  The problem is that
> > > garbage collector invoked form the middle of SSA compilation path (not
> > > done in official tree) zaps the free list of nodes.
> > 
> > Can you try to work out why zapping a freelist should produce
> > different results?  It shouldn't.
> > 
> > If you find that bug, then this patch is unnecessary.
> It is not bug and this patch also saves memory.
> It is same as with RTL - if you change register numbers, you change
> hashtables and you change decisions in some corner cases.  This is IMO
> OK and it is very wrong to have different SSA_VERSIONs depending on GGC
> decisiosns.

Perhaps this is not very clear.
The Jeff's code maintain list of free SSA_NAME nodes.  Each SSA_NAME has
associated SSA_NAME_VERSION integer that is unique.  Normally
SSA_NAME_VERSIONs are asigned sequentially but as an optimization Jeff's
code re-use old SSA_NAME_VERSIONs of free nodes.  This ends up in less
memory consumption by arrays indexed by version.

WHen GGC flush out SSA_NAME list, the tree-ssaname will assign new
SSA_NAME_VERSIONs instead of reusing old one.  This results in different
order of optimization done by some passes that work on one SSA_NAME at
time, differences in dump files and in turn also differences in
resulting assembly and debug output.

This is why I believe it makes sense to ensure re-use of
SSA_NAME_VERSIONS always.  I've checked that this is important factor
(my first try on this patch simply killed the re-use of
SSA_NAME_VERSIONS and kept only re-use of SSA_NAME nodes and this
resulted in growth of memory usage from 142MB to over 150MB even with
the new feature of global re-use of SSA_NAMEs over function
compilations).

The problem is not that some pass depends on precise memory layout, that
would be a bug in that pass, but that we produce different intermediate
representation depending on GGC decisions that is a bug in underlying
infrastructure.

Honza
> 
> Honza
> > 
> > -- 
> > - Geoffrey Keating <geoffk@geoffk.org>