On December 5, 2015 11:57:27 PM GMT+01:00, Gary Funck <g...@intrepid.com> wrote: >On 12/02/15 10:40:50, Richard Biener wrote: >> On Tue, 1 Dec 2015, Gary Funck wrote: >> > The main change recommended to reduce tree space was moving the >> > "layout factor" (blocking factor) out of the tree node, and using >> > only two bits there, one bit for a relatively common case of 0, >> > and the other for > 1. It was suggested that we use a hash >> > table to map tree nodes to layout qualifiers for the case they >> > are > 1. This necessitated using a garbage collected tree map, >> > which unfortunately meant that tree nodes needed special garbage >> > collection logic. >> >> I still don't see why it needs special garbage collection logic. >> We have many tree -> X maps that just get away without. >> [...] >> As said, I don't see why you need a special GC collection logic >> at all. Please explain. > >The problem we ran into is that we had a tree map which >mapped a tree node to its UPC layout qualifier, which >is an integral constant (CST). Tree nodes for CST's >are made unique by hashing them into an integer->tree map. >What happened is that the GC would free up entries in the >CST table that were being used by the layout qualifier map. > >It seems that the new tree map logic fixes this problem >(as you've noted). I backed out the custom GC logic and >re-ran a large test that extensively exercises the use case >that triggers the issue -- works like a charm.
That's good news! Richard. >thanks, >- Gary
