On Fri, 18 Jan 2019, Jakub Jelinek wrote: > On Thu, Jan 17, 2019 at 03:43:05PM +0100, Jakub Jelinek wrote: > > > So we do not care to optimize this to only clobber the vars that > > > are appear live over the EH edge? > > > > Wouldn't that be quite expensive (especially at that spot in the inliner)? > > I could surely defer that (at the spot in copy_edges_for_bb just remember > > which bb was it and handle it before destroying the decl_map in > > expand_call_inline, but: > > 1) are the extra CLOBBERs that big a deal?
No idea. Can you see how many we add (and to have a comparison how many were there before) when, say, building libstdc++? (bootstrap has -fno-exceptions to that's not a good test, maybe some other (smaller) C++ application?) > > 2) if they are, shouldn't we have a pass that does it generically after IPA > > and removes all CLOBBERs for vars already known dead, whether they come > > from inlining or whatever else (we have many in the IL already that are > > dead for other reasons, e.g. a variable where the destructor is inlined > > and has one CLOBBER in itself, but have another CLOBBER in the caller too > > when the var goes out of scope); tree DSE is able to remove CLOBBERs for > > the same var if they are adjacent; in either case, what would be the > > algorithm for that? Something like add_scope_conflicts algorithm, just > > not build any conflicts, but just propagate the var is live bitmaps > > and when the propagation terminates, go through all bbs and if it sees > > a clobber on a var that isn't live at that point, remove the clobber? > > That said, I think it would be doable also in the inliner if you prefer to > do it there for now, and for GCC10 other passes could use that for other > purposes. > > I'd do it in copy_cfg_body before we destroy the ->aux fields mapping src_fn > bbs to dst_fn blocks, pre_and_rev_post_order_compute_fn (id->src_cfun, ...) > + have a bitmap previously computed of interesting decls to track liveness > of (for later uses if the bitmap is NULL it could track all VAR_DECLs that > need to live in memory) and do the liveness propagation similarly to what > add_scope_conflicts does on the src_cfun bbs, then in the end just look at > srcs of EDGE_EH edges that are >= last and see what vars are live at the end > of those bbs from the bitmaps. I wonder if instead of tracking interesting vars we can compute local live-in/out during actual BB copying and then just iterate the global problem for the part going into the interesting EH edges? OTOH doing all this smells like a source of quadraticness so I hope it won't be necessary or we can instead use some heuristics to prune the set of vars to add clobbers for (can we somehow use BLOCK_VARs of the throws?) if the numbers say it looks necessary. But yes, adding them all during inlining and then having a way to prune them later would be another option. I don't want to be too clever for GCC 9 since we're quite late so another option is to limit the number of clobbers generated (just generate them for the top N of vars sorted by size (prioritizing variable-sized ones)?). Richard.
