Put scope blocks on a diet

[Jan Hubicka]

Hi,
> On Nov 28, 2007, Mark Mitchell <mark@codesourcery.com> wrote:
> 
> > True -- but it is consistent across runs and across hosts.  Unless the
> > UIDs vary when you add -g, which, empirically, they do.
> 
> For the record, before the July 2[46] patch, they didn't.  After that
> patch, they did.  And, ever since I started caring deeply about them
> (when I started the VTA project), that was the only regression and the
> only detail I had to fix to keep DECL_UIDs in sync comparing -g and
> -g0.
> 
> My suggestion is that, when not emitting debug information, instead of
> keeping unused decls around in the binding blocks, we replace them
> with placeholders, such that, at inlining time, instead of cloning
> the declarations they would have represented, we can merely bump up
> the decl uid counter.

I've considered of just building stripped down decls for those purposes,
however I don't like the idea much - we still will have a lot of
overhead linking those things together and producing a lot of binding
blocks that are memory consuming too.

Do you see any direct problem in the plan of simply not copying those at
-g and teaching debug info output to look into ABSTRACT_ORIGIN of the
block and see what dead variables should be added as "optimized out" I
proposed yesterday?
> 
> This *would* keep UIDs in sync with a far less destabilizing effect.
> However, I can't tell for sure that none of the removed decls would
> have made to hash tables elsewhere, which could potentially
> destabilize the compiler output by changing hashtable walk order
> because of changes in the hashtable size.  I don't quite *see* how

We do have a lot of algorithms drived by DECL_UIDs and thus those needs
to stay in sync.  Having different representation of those dead
variables not appearing in hashtables should not cause much harm IMO.
They are not apperaing in referenced/unreferenced var lists so they are
essentially invisible to all SSA code.

Honza
> unused variables would make it elsewhere, and it's simple enough that
> it's probably worth a shot.  But I can't promise it's going to work.
> 
> -- 
> Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
> FSF Latin America Board Member         http://www.fsfla.org/
> Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
> Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}