On Wed, Feb 19, 2020 at 4:12 PM Richard Sandiford <richard.sandif...@arm.com> wrote: > > 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.
No idea - you could print the rtxen involved to a temporary file and look at them... when I did that other statistic most cases were from postreload DSE (which does O(n^2) disambiguations...) against stack slots. >From what I've seen we're definitely eager to drop MEM_EXPR and lack handling of late allocated stack space there. > > 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
