https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98228
--- Comment #14 from Marius Hillenbrand <mhillen at linux dot ibm.com> ---
Comparing x86-64 to s390x, modref_may_conflict makes a mistake when analyzing
whether the called function Get_Next_Interp because of incomplete data on alias
sets. That specific analysis involves alias sets 2, 5, and 6, which are missing
in vec<alias_set_entry *, va_gc> *alias_sets on s390x, while they are present
on x86-64. (I'm using -flto-partition=max and only looking at a single LTO
partition of an affected function)
looking at loops of this kind:
while Present (It.Typ) loop
Get_Next_Interp (I, It);
end loop;
optimization goes off the rails because ipa-modref makes incorrect claims about
Get_Next_Interp and how it handles "It" (a padding around a record of type info
in the Ada frontend, the variable used like an iterator).
ipa-modref: call to sem_type__get_next_interp/2320 does not clobber ref:
it.F.typ alias sets: 5->5
ltrans.085i.modref claims to read ok data on both x86-64 and s390x,
Read modref for sem_type__get_next_interp/2320
loads:
Limits: 32 bases, 16 refs
Base 0: alias set 1
Ref 0: alias set 1
Every access
Base 1: alias set 2
Ref 0: alias set 2
Every access
stores:
Limits: 32 bases, 16 refs
Base 0: alias set 2
Ref 0: alias set 2
access: Parm 1 param offset:0 offset:0 size:96 max_size:96
parm 0 flags: direct noclobber noescape nodirectescape
parm 1 flags: direct noescape nodirectescape
yet the alias set 2 does not show up on s390x. The padding record (type of It)
has an alias-set in its type-decl (5 on s390x, 6 on x86) yet that does not show
up in alias.c:alias_sets. Further, the record-type sem_type__interp (i.e.,
it.F, inside the padding) has alias set 2 assigned on x86-64, which matches the
loaded modref data, but has alias-set -1 on s390x.
Another discrepancy: the record-type decl sem_type__interp is flagged
unaddressable and has TImode on s390x vs BLKmode on x86-64 (and not flagged
unaddressable). Could that flag cause the type to not get associated an
alias-set?
