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?
> 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.
Jakub
