https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118924
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot
gnu.org
CC| |rguenth at gcc dot gnu.org
Status|ASSIGNED |NEW
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
So the issue with the C++ frontend is that the load
E primType = *begin;
does not alias the initialization
E types[3] = {POINTS, LINES, TRIANGLES};
due to TBAA.
<array_ref 0x7ffff6741038
type <integer_type 0x7ffff68235e8 int sizes-gimplified public type_6 SI
size <integer_cst 0x7ffff681a480 constant 32>
unit-size <integer_cst 0x7ffff681a498 constant 4>
align:32 warn_if_not_align:0 symtab:0 alias-set 2 canonical-type
0x7ffff68235e8 precision:32 min <integer_cst 0x7ffff681a438 -2147483648> max
<integer_cst 0x7ffff681a450 2147483647>
pointer_to_this <pointer_type 0x7ffff682ab28>>
arg:0 <var_decl 0x7ffff671f558 types
type <array_type 0x7ffff6732690 type <enumeral_type 0x7ffff6726738 E>
vs.
<mem_ref 0x7ffff673a0c8
type <enumeral_type 0x7ffff6726738 E
type <integer_type 0x7ffff68235e8 int sizes-gimplified public type_6 SI
size <integer_cst 0x7ffff681a480 constant 32>
unit-size <integer_cst 0x7ffff681a498 constant 4>
align:32 warn_if_not_align:0 symtab:0 alias-set 2 canonical-type
0x7ffff68235e8 precision:32 min <integer_cst 0x7ffff681a438 -2147483648> max
<integer_cst 0x7ffff681a450 2147483647>
pointer_to_this <pointer_type 0x7ffff682ab28>>
sizes-gimplified type_5 type_6 SI size <integer_cst 0x7ffff681a480 32>
unit-size <integer_cst 0x7ffff681a498 4>
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7ffff6726690 precision:32 min <integer_cst 0x7ffff681a438 -2147483648> max
<integer_cst 0x7ffff681a450 2147483647>
values <tree_list 0x7ffff6729320
purpose <identifier_node 0x7ffff6725700 POINTS
normal local bindings <(nil)>> value <const_decl 0x7ffff6805780
POINTS>
chain <tree_list 0x7ffff6729348
purpose <identifier_node 0x7ffff6725740 LINES
normal local bindings <(nil)>> value <const_decl
0x7ffff68057f8 LINES>
chain <tree_list 0x7ffff6729370
purpose <identifier_node 0x7ffff6725780 TRIANGLES
normal local bindings <(nil)>> value <const_decl
0x7ffff6805870 TRIANGLES>>>> context <translation_unit_decl 0x7ffff6821000 t.c>
pointer_to_this <pointer_type 0x7ffff67327e0> chain <type_decl
0x7ffff6705dc0 E>>
arg:0 <ssa_name 0x7ffff67335e8
on GENERIC we have
<<cleanup_point ED.4500 typesD.4542[3] = {0, 1, 2};>>;
{
gimplified to
typesD.4542 = *.LC0D.4557;
and SRAed to
typesD.4542[0] = SR.4_14;
the C frontend likely uses an integer type for the indirect enum access
that is compatible with the plain int type used by SRA.
It looks like SRA is confused by the .LC0 initializer having array of integer
rather than array of Enum type and it takes that as a model for building
the LHS access. That model is created by totally_scalarize_subtree
from the integer type constant decl which is eventually created from the
integer array type CONSTRUCTOR emitted by the C++ frontend:
<constructor 0x7ffff6724690
type <array_type 0x7ffff67262a0
type <integer_type 0x7ffff68235e8 int sizes-gimplified public type_6 SI
size <integer_cst 0x7ffff681a480 constant 32>
...
constant static length:3
idx <integer_cst 0x7ffff681a270 type <integer_type 0x7ffff6823000 sizetype>
constant 0>
val <integer_cst 0x7ffff681a5d0 type <integer_type 0x7ffff68235e8 int>
constant 0>
idx <integer_cst 0x7ffff681a348 type <integer_type 0x7ffff6823000 sizetype>
constant 1>
...
it is of course naiive for SRA to use a model that's not TBAA compatible
with the original aggregate store, but the C++ frontend isn't helpful here
in emitting this kind of assignment.
Leaving to Martin to figure where to plug this in SRA.
