On Tue, Nov 24, 2020 at 12:14 PM Marius Hillenbrand
<mhil...@linux.ibm.com> wrote:
>
> On 11/23/20 12:04 PM, Richard Biener wrote:
> > On Mon, Nov 23, 2020 at 10:53 AM Marius Hillenbrand via Gcc
> > <gcc@gcc.gnu.org> wrote:
> >>
> >> Hi,
> >>
> >> Digging into a test case failure with section anchors, I found
> >> dependence analysis return false negatives, leading to bad optimization
> >> by cse1. Two variables are synthetically constructed aliases. One is
> >> addressed relative to the section anchor and the other using a symbol
> >> ref, yet write_dependence_p() claims that they could not alias. I can
> >> reproduce that miscompile on aarch64, ppc64, and s390x. How is
> >> write_dependence_p() supposed to handle such cases with section anchors?
> >>
> >>
> >> Example: (simplified version of gcc.c-torture/execute/alias-2.c)
> >> int off; // causing nonzero offset of a to the section anchor
> >> int a;
> >> extern int b __attribute__ ((alias("a")));
> >> /* ... */
> >> int main()
> >> b=1; <-- uses symbol_ref to b
> >> a=2; <-- uses the section anchor + offset 4
> >> if (b!=2)
> >> __builtin_abort ();
> >> return 0;
> >> }
> >>
> >> so write_dependence gets to compare the canonicalized addresses
> >> (const:DI (plus:DI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
> >> (const_int 4 [0x4])))
> >> and
> >> (symbol_ref:DI ("b") [flags 0x602] <var_decl b>)
> >> and
> >>
> [...]
> >
> > If the above is all we get to see then we have to give up when either
> > of the address is based on a section anchor and we know the other
> > one could possibly be refered through a section anchor.
> >
> > In those cases we have to rely on MEM_EXPRs for disambiguation
> > which, for the anchored address, is unfortunately lost?
>
> Actually, both mem rtx have their MEM_EXPRs attached, in the cases I
> looked at.
>
> for example
> (mem/c:SI (const:DI (plus:DI
> (symbol_ref:DI ("*.LANCHOR0") [flags 0x182])
>
>
> (const_int 4 [0x4]))) [1 a+0 S4 A32])
>
> We could add a check for cases where MEM_EXPRs are available and clearly
> indicate aliasing or overlap. That check would happen before the other
> methods that only look at partial information (e.g., base_alias_check,
> memrefs_conflict_p) -- to catch such clear cases without the risk of
> making the other checks more pessimistic.
But you can't rely on must-alias for may-alias queries so that will just
paper over the existing issue in most of the cases ...
Richard.
>
>
> >
> >> (see also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92294 for the
> >> initial report on aarch64 and my full example)
> >>
> >> Marius
>
> --
> Marius Hillenbrand
> Linux on Z development
> IBM Deutschland Research & Development GmbH
> Vors. des Aufsichtsrats: Gregor Pillen / Geschäftsführung: Dirk Wittkopp
> Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht
> Stuttgart, HRB 243294
