On Tue, Jan 21, 2020 at 8:09 PM Jan Hubicka <hubi...@ucw.cz> wrote:
>
> > On January 21, 2020 4:37:31 PM GMT+01:00, Jan Hubicka <hubi...@ucw.cz>
> > wrote:
> > >Hi,
> > >this patch fixes ICE causes by call stmt site hash going out of sync.
> > >For
> > >speculative edges it is assumed to contain a direct call so if we are
> > >removing it hashtable needs to be updated. I realize that the code is
> > >ugly
> > >but I will leave cleanup for next stage1.
> > >
> > >Bootstrapped/regtested x86_64-linux. This patch makes it possible to
> > >build
> > >Firefox again.
> >
> > It even looks quadratic? Can't you simply lookup the stmt?
>
> I am not sure what you mean by looking up the stmt. To go from stmt to
> call edge you either walk the callees chain or use call_site_hash that
> populates itself when you have more than 100 callees. The situation
> this code solves is that with speculative calls have multiple direct
> edges, one indirect and multiple refs associated with the speculated
> call stmt. Now one of direct edges gets removed and at this moment one
> needs to look up different one to re-populate the hash.
I see. I thought that maybe we have the hash record stmt -> { set of edges }
but if we have only stmt -> single-edge then indeed that's bad.
> I meant to fix the ICE first, but indeed resolve_speuclations and
> redirect_stmt_to_callee is O(num_callees+num_refs) in worst case here
> which needs to be fixed (though the case is quite rare in practice).
At least isolating this "detail" into a function might be nice...
> One can keep direct edges in a block in the lists (with verifier help),
> but still looking up referneces is bit hard since they are in vector and
> that is re-numbered on inserts and deletes. I plan to fix this
> incrementally (we want also refs hash and verifier for the caches, plus
> this all is memory use critical)
Thanks,
Richard.
>
> Honza
