https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91020
Martin Jambor <jamborm at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2019-06-27
Ever confirmed|0 |1
--- Comment #1 from Martin Jambor <jamborm at gcc dot gnu.org> ---
The principal problem with the first (C++) testcase is that the
SRA thinks the DECLs need to live in memory:
Rejected (2241): needs to live in memory: D.2241
Rejected (2240): needs to live in memory: D.2240
That is because the IL contains:
_27 = .GOMP_SIMD_LANE (simduid.0_15(D), 2);
_28 = &D.2241[_27];
_29 = &D.2240[_27];
_36 = MEM[(int *)_29];
_38 = MEM[(int *)_28];
and the ADDR_EXPR makes them addressable and thus a big problem for SRA.
The second (C) testcase does not have this problem. SRA sees two
(unscalarizable) accesses to the DECL, one represented by
D.2128[_45].p, offset 0 and (max) size 1024, another represented by
D.2128[_45].m, offset 32 and (max) size 992. It is a good thing that
get_ref_base_and_extent does not recognize the first one as spanning
only up to 992, otherwise we would get partial overlap, which SRA
really dislikes and cannot cope with. I wonder if this behavior of
get_ref_base_and_extent can be relied on, though.
