> On Jan 22, 2015, at 7:53 PM, Rafael Espíndola <[email protected]> > wrote: >> Yuck. How expensive is a TrackingVH? Since we're moving towards having >> lots of DeferredGlobals, do we need to worry about this? > > It is a hash table lookup on rauw. > > When we return false from MayBeEmittedEagerly, we add entries where > GV is null. The only reason we ever store a GV is to save on duplicated > lookups > of the mangled name during the emission of deferred decls. > > If we were to deffer all, I think we could probably avoid even computing > mangled > names before EOF. Just remember all the GD in a plain vector. At EOF, > mangle each and > > * If required: output: > * It GV already created, it was used: output. > * Else, set DeferredDecls[MangledName] in case we find a use. > >> If you think the cost is fine, then this LGTM; otherwise, I suppose >> we'll need to find another approach. > > Attached is a second patch (on top of the first one) that just removes GV > from the delay list. This trades not needing a TrackingVH for a second > looked by the mangled name. This is probably on the correct path if we > are going to delay more. Otherwise a TrackingVH is probably cheaper > as RAUW is not that common in clang. What do you think?
I think the TrackingVH is fine. John. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
