On 04/11/2016 03:42 PM, Nathan Sidwell wrote:
This proto patch addresses 70594, where the constexpr machinery causes
differences in -fcompare-debug checking. I'm looking for initial
comments about the approach this patch is taking.
As described in the comments of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70594 the change is being
caused by differing GC points with and without debug info generation.
We generate different patterns of DECL_UID.
I still think that -fcompare-debug being sensitive to exact DECL_UID is
the real bug here.
With Patrick's patch to address 70542 constexpr_call_table is now
gc-deletable, and he introduced a cache for constexpr fn bodies, also
gc-deletable.
This patch changes things so that both constexpr_call_table and
fundef_copies_table are no longer gc-deletable. Instead we simply count
the size of the constexpr_call_table and manually delete it if it gets
'too big'.
Why do we need to change constexpr_call_table at all? If we stop
discarding fn copies, so we consistently make the same number of copies,
DECL_UID should be stable.
The bulk of this patch is adding gc machinery to the
fundef_copies_table_t type, as we now need to walk it during GC.
Why do you need ((user)) machinery? There are plenty of simple GTY(())
hash_maps in the source.
I've added a new hook to delete these two tables at the end of parsing.
This is called from c_parse_final_cleanup. There's no point having them
hang around during the rest of compilation.
Agreed.
1) I think this approach is not globally best. We're inventing another
memory-usage related heuristic, rather than relying on the already
available GC machinery. That's why I've gone with a hard coded value
for now, rather than add a new user-frobable param. The right solution
is to stop generating new DECL_UIDs when copying fns for constexpr
evaluation. IIUC the UID is being used to map decls to values. I don't
see why we can't just use the (copied) DECL's address as a key to find
its associated value (but I've not investigated that approach).
The mapping is already from the decl's address.
2) The constexpr_call_table and fundef_copies_table are closely related
data structures. I think it would be cleaner to combine these into a
single data structure. Possibly along with the call_stack and
associated variables. Such a cleanup would be good even if we don't go
with this approach to the defect, but could wait until 7.0. If we go
with this approach, IMHO it would be good to do some of this merging now.
As Patrick observed, it makes more sense to tack the copies onto the
constexpr_fundef_table.
Jason
