Patch ping (was Re: [WIP PATCH] Improve tail call analysis and inliner EH clobber through variable life analysis (PR tree-optimization/89060))

Jakub Jelinek jakub@redhat.com
Mon May 6 15:09:00 GMT 2019


On Mon, May 06, 2019 at 04:17:01PM +0200, Richard Biener wrote:
> > > +  vec<bitmap_head> active;
> > > +  /* Work bitmap of currently live variables.  */
> > > +  bitmap work;
> > > +  /* Bitmap of interesting variables.  Variables with uids not in this
> > > +     bitmap are not tracked.  */
> > > +  bitmap vars;
> > > +};
> 
> How dense are the bitmaps?  Storage requirement will be quadratic
> so eventually using a sparseset for 'vars' and using the sparseset
> index for the bitmaps will improve things?  Or re-using live

I'll gather some statistics.  I was using bitmaps because expansion uses
them for the same purpose as well.

> > > +  for (gsi = gsi_after_labels (bb); !gsi_end_p (gsi); gsi_next (&gsi))
> > > +    {
> > > +      gimple *stmt = gsi_stmt (gsi);
> > > +
> > > +      if (gimple_clobber_p (stmt))
> > > +	{
> > > +	  tree lhs = gimple_assign_lhs (stmt);
> > > +	  if (VAR_P (lhs) && bitmap_bit_p (data->vars, DECL_UID (lhs)))
> > > +	    bitmap_clear_bit (data->work, DECL_UID (lhs));
> 
> I think this clearing causes PR90348.

But if we remove it, we totally kill all the stack slot sharing I'm afraid.
Looking at that PR now.

> I wonder if it is possible to split analysis and transform here
> some more - the above is called for all preds of EXIT, if we
> first analyze all of them and then compute live once if needed,
> pruning invalid ones and then doing transform this would at least
> make LIVE only computed once.

Yeah, that is something I've mentioned in the mail with the patch, possibly
compute on the first tail call being analyzed for all other tail calls and
then for each one just walk the single bb once again.
> 
> It should be also possible to restrict LIVE to the sub-CFG leading to
> the EXIT preds with tail-call candidates as well, no?

Not sure how.  Especially if we compute for all tail calls.

	Jakub



More information about the Gcc-patches mailing list