On Wed, May 08, 2019 at 03:51:42PM +0200, Richard Biener wrote:
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> I'm still worried about complexity - for the inliner case we compute
> liveness for the whole destination function for each function with
> an EH landing pad we expand inline. It seems to me the liveness
No, in the inliner we compute it for the whole callee body only:
vec<bitmap_head> live = compute_live_vars (id->src_cfun, vars);
caller body would be id->dest_cfun instead.
> should be computed on the callee function body, not the caller
> after inlining? Is it really worth optimizing the number of clobbers
> here with this potentially expensive work?
I've seen in several testcases that we were adding big amounts of clobbers
and that is something we really won't get rid until RTL expansion, if it is
in functions we inline further it will be duplicated etc.
> For the tailcall case consider a function like
>
> foo ()
> {
> T a, b, ....;
> if (..) baz(&a);
> if (..) baz(&b);
> ...
> bar(&a,&b,&c...);
> }
>
> or similar, that is, a lot of decls we need to track, a lot of BBs
> and a lot of tailcall opportunities with the case of all decls being
> live throughout the whole function.
True, sure, there can be corner cases with many variables. On the other
side, the tail call optimization is in some cases very important for some
programs (actually required in some cases where e.g. the recursion is very
deep), so I think the optimization is worth it.
If we run into some corner cases, we could punt if we e.g. notice that the
number of variables to check is too high with too large cfg.
> -foptimize-sibling-calls is only enabled at -O2 but the inlining
> part at -O1 where we hit those huge auto-generated testcases.
If we want, we could either just for -O1 or all cases again punt if the cfg
is too large and/or number of variables is too large.
Jakub
