https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93946
--- Comment #15 from sandra at gcc dot gnu.org ---
Hmmm. I've gone over this code 2 or 3 times now, and I'm still convinced the
problem is in the alias analysis, not the scheduler.
I've stepped deeper into the code in the debugger, and here is the backtrace
from where I see things going wrong:
#0 indirect_refs_may_alias_p (ref1=0x7ffff74196f0, base1=0x7ffff73fec08,
offset1=..., max_size1=..., size1=..., ref1_alias_set=1,
base1_alias_set=4, ref2=0x7ffff74195d0, base2=0x7ffff73febb8, offset2=...,
max_size2=..., size2=..., ref2_alias_set=1, base2_alias_set=6, tbaa_p=true)
at /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/tree-ssa-alias.c:2122
#1 0x00000000013f8266 in refs_may_alias_p_2 (ref1=0x7fffffffd7d0,
ref2=0x7fffffffd790, tbaa_p=true)
at /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/tree-ssa-alias.c:2320
#2 0x00000000013f82bb in refs_may_alias_p_1 (ref1=0x7fffffffd7d0,
ref2=0x7fffffffd790, tbaa_p=true)
at /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/tree-ssa-alias.c:2339
#3 0x0000000000b90b06 in rtx_refs_may_alias_p (x=0x7ffff742cac8,
mem=0x7ffff742c9a8, tbaa_p=true)
at /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/alias.c:365
#4 0x0000000000b981de in true_dependence_1 (mem=0x7ffff742c9a8,
mem_mode=E_SImode, mem_addr=0x7ffff742c7e0, x=0x7ffff742cac8,
x_addr=0x7ffff742c798, mem_canonicalized=false)
at /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/alias.c:3048
The code here says
/* Do type-based disambiguation. */
if (base1_alias_set != base2_alias_set
&& !alias_sets_conflict_p (base1_alias_set, base2_alias_set))
return false;
and the "false" return status gets propagated all the way back up to
true_dependence.
It seems to me that what is going wrong is that it is failing to consider that
two pointer parameters can be aliased no matter what their declared type is,
and no matter what types they are cast to -- e.g. because they point to members
of the same union. Should ao_ref_base_alias_set be putting everything based on
pointer parameters without restrict semantics into the same alias set, maybe?
Or should there be some code in indirect_refs_may_alias_p to look for this
situation before it reaches the point of type-based disambiguation where it is
currently failing to DTRT?
