Richard Biener <richard.guent...@gmail.com> writes: > On Wed, Feb 19, 2020 at 1:19 PM Richard Sandiford > <richard.sandif...@arm.com> wrote: >> >> What should we do about this? The PR is a wrong-code regression from >> GCC 9 and it doesn't look like we can remove the second offset_overlap_p >> check, given how many cases currently rely on it. > > Did you check whether we eventually disambiguate those via > rtx_refs_may_alias_p > (so using MEM_EXPR)? I would guess all but those that have no MEM_EXPR?
Good point, I should have checked that. Here are the numbers after excluding cases that mems_in_disjoint_alias_sets_p, nonoverlapping_memrefs_p and rtx_refs_may_alias_p would disambiguate later. This time I didn't divide based on false/true, just based on the path taken: cmp == 1, overlap: : 66.72% cmp == 1, no overlap : 6.51% cmp == -1, overlap : 0.06% cmp == -1. no overlap : 26.71% <--- the number that matters The number of cases being disambiguated only by this function seems surprisingly high. Maybe that's a sign that we're losing too much information somewhere? Or maybe it's rtl constants vs. other stuff. > Ideally we'd rely more on MEM_EXPR for alias disambiguation than the ad-hoc > ways of recovering "details" from the actual MEM. Yeah, agreed. Thanks, Richard
