This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


In message <20031130134252.GB5334@kam.mff.cuni.cz>, Jan Hubicka writes:
 >> > 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.
Please stop.

1. Re-using SSA_NAMES across different functions is a bad idea.  Please let's
   not do that.  The whole point of the SSA_NAME cache is to avoid silly 
   GC allocations within the SSA path for a single function.

2. Long term SSA_NAME management needs to go away.  

   2a. First we need to be able to GC between the SSA passes.

   2b. We need to be able to tell the GC system that a particular object
       is no longer being used and that the GC system should re-use that
       memory if it is convenient to do so.




So rather than muck around making SSA_NAME (or PHI_NODE) management more
complex, let's instead address the underlying GC issues.


Jeff





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]