https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #38 from aldy at quesejoda dot com --- On Tue, Sep 17, 2024 at 1:19 PM rguenther at suse dot de < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855 > > --- Comment #37 from rguenther at suse dot de <rguenther at suse dot de> > --- > On Tue, 17 Sep 2024, aldyh at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855 > > > > --- Comment #36 from Aldy Hernandez <aldyh at gcc dot gnu.org> --- > > (In reply to Richard Biener from comment #33) > > > Can we just sort m_paths after the path entry BB and fix the lookup > that way? > > > > This seemed promising, especially because the > adjust_paths_after_duplication() > > gets called from the backwards threader in order, and always starting at > > position 0, so searching for the first item would be super fast. > However, this > > function will rewire the edges in the path > (rewire_first_differing_edge), thus > > messing up the sort. > > Bah. Remove those "fixed" candidates from the set (dropping 2nd level > opportunities that way)? Alternatively sort m_paths into a better > Yeah, that's exactly what I thought. I doubt we're getting much from 2nd level subpaths. > data structure (IIRC we only have splay-tree as binary tree) for > the purpose of the lookup and re-place fixed up paths (but keep > m_paths for the purpose of processing things). > Yeah, ultimately this is a data structure problem. I'll poke a bit more tomorrow.
