https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106514
--- Comment #1 from Andrew Macleod <amacleod at redhat dot com> --- (In reply to Richard Biener from comment #0) > > Part of the sub-optimality is probably the equiv chain becoming very long > (can we simply limit that?) and clearing bits in all the very many > bitmaps linked. N we certainly could. Especially in the path version which has that killing-def issue which doesn't exist in the normal oracle. The path oracle basically takes a normal oracle, then bolts the path following code onto it, and has to deal with new defintions invalidating any existing equivalences. I'd first look for inefficiencies elsewhere as we didnt spend a lot of time tweaking it once it was working. Given the way equivalences have to be matched, Im not sure that we even need to walk the list. The new equivalence set for the killed def will only contain itself, or any new equivalences encountered since the kill. In order to be equivalent, 2 names must be in each others set, which they won't be. I'm not convinced we need to remove them at all. Im also not sure why the path oracle changes the root oracle requirement that they be the same equivalence set, not just in each others. I think it has something to do with the transitory nature of the path equivalence/relations vs the root oracles "permanent" sets. I think we can do better here too. And finally, Aldy has a list of all the ssa-names in the path that are relevant to the calculations in the path. I suspect we can reduce any equivalence sets immediately to just those names, as any on-entry ranges should reflect existing equivalences. in theory :-) We'll see if any or all of those have any effect and get back to you.
