This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] Avoid nondeterminism in tree-ssanames
> > Jan Hubicka <email@example.com> 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
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
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
> > --
> > - Geoffrey Keating <firstname.lastname@example.org>