On Tue, 2020-01-14 at 11:02 +0100, Jakub Jelinek wrote: > On Mon, Jan 13, 2020 at 11:51:53PM -0500, David Malcolm wrote: > > > * cfg.s correctly has a call to memset (even with no > > > optimization) > > > for > > > hash_table<bb_copy_hasher>::empty_slow > > I have intestigated unpatched cc1plus and in the (usually inlined) > alloc_entries I see in all the places the xcalloc or > ggc_internal_cleared_alloc > followed by either a loop storing some zeros or a memset, which is > something > I'd hope the patch also improves.
It does: I looked at tree-ssa.s, at the alloc_entries code generated for: static hash_map<edge, auto_vec<edge_var_map> > *edge_var_maps; In an unoptimized build: Before the patch I see the loop in the .s calling mark_empty after the calls to data_alloc and ggc_cleared_vec_alloc; After the patch there's no longer that loop in the generated .s With -O2 it's harder to follow as the ctor gets inlined into redirect_edge_var_map_add, but: Before the patch there's a loop that's zeroing the keys after the call to ggc_internal_cleared_alloc After the patch that loop isn't present. > As for graphite.c, sure, empty_zero_p = false is a fallback value, > the > question was not directly related to this patch, but rather wondering > how it > can work at all. > > > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu (in > > conjuction with the analyzer patch kit, which it fixes) > > > > OK for master? > > Yes to both patches, thanks. Thanks. I rebased and did another bootstrap®ression test with just patch 1 to be sure. I've pushed it to master as 7ca50de02cf12c759f4f8daf60913704782b7d45. I've rebased and squashed the analyzer patch kit and squashed patch 2 into it, and am re-testing it now. Dave
