[PATCH 4/5] Downgrade value_expr_for_decl to non-cache

Jakub Jelinek jakub@redhat.com
Wed Jul 15 15:12:00 GMT 2015


On Wed, Jul 15, 2015 at 04:52:41PM +0200, Michael Matz wrote:
> On Wed, 15 Jul 2015, Michael Matz wrote:
> 
> > Similar for "ptr->foo" if "ptr" is nowhere mentioned in code or tables.  
> > In effect DECL_VALUE_EXPR refers to stale decls that aren't initialized, 
> > aren't given a place and aren't dealt with in code.
> 
> Or, maybe we're talking past each other.  You mean the case where 
> complicated-expr-on-Y is the value-expr, and Y is _no_ stale decl, but the 
> complicated expr itself nevertheless is mentioned nowhere else?  Yes, 
> those trees must be retained, I was only talking about the stale-decl 
> cases.

I meant primarly all those ADDR_EXPRs, MEM_REFs, INDIRECT_REFs, ARRAY_REFs,
etc.  For referenced decls in there if they aren't referenced from anywhere
else, not 100% sure about it.  DECL_VALUE_EXPR is mainly used during
gimplification, and then for debug info production, DECL_DEBUG_EXPR too.
For debug info, I bet if the underlying decls referenced in there will not
exist, then we'd just give up in debug info generation of the particular
object, but wonder if gcc won't ICE if you have the flag bits like
DECL_HAS_VALUE_EXPR_P set and then DECL_VALUE_EXPR of NULL, if you'd
GC them.

Another option for GC these might be to gc walk DECL_VALUE_EXPR of
decls that have DECL_HAS_VALUE_EXPR_P set, similarly for DECL_DEBUG_EXPR,
and then treat those hash maps as pure caches, entries with unmarked
keys would be removed, and no walking of trees referenced from the hash map
would be performed directly.

	Jakub



More information about the Gcc-patches mailing list