https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99919
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed|2021-11-30 00:00:00 |2023-12-15
CC| |jamborm at gcc dot gnu.org
--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
This is also a missed SRA optimization. SRA produces
b$i_16 = b.i;
b$j_17 = b.j;
b.i = b$i_16;
b.j = b$j_17;
_1 = VIEW_CONVERT_EXPR<unsigned char>(b);
_2 = _1 & 1;
...
b.i = b$i_16;
b.j = b$j_15;
_4 = VIEW_CONVERT_EXPR<unsigned char>(b);
_5 = _4 & 2;
which is sub-optimal - for some reason it chooses to create replacements
for i and j instead of a unsigned char replacement for the whole
aggregate driven by the V_C_E access
access { base = (2771)'b', offset = 0, size = 8, expr = b, type = struct B,
reverse = 0, grp_read = 1, grp_write = 0, grp_assignment_read = 1,
grp_assignment_write = 0, grp_scalar_read = 0, grp_scalar_write = 0,
grp_total_scalarization = 0, grp_hint = 0, grp_covered = 0,
grp_unscalarizable_region = 0, grp_unscalarized_data = 1, grp_same_access_path
= 1, grp_partial_lhs = 0, grp_to_be_replaced = 0, grp_to_be_debug_replaced = 0}
is also odd because the access type is really 'unsigned char'? That seems
to be because
/* We need to dive through V_C_Es in order to get the size of its parameter
and not the result type. Ada produces such statements. We are also
capable of handling the topmost V_C_E but not any of those buried in other
handled components. */
if (TREE_CODE (expr) == VIEW_CONVERT_EXPR)
expr = TREE_OPERAND (expr, 0);
but I couldn't easily convince it to do sth here (and dumps turn out
empty as for reasoning of disqualification).
