https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93411
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Richard Biener from comment #2) > There's also already a bug about this (can't find it quickly enough). IIRC > my concerns were > > 1) it should be done during propagation to catch 2nd level opportunities > 2) for compile-time some pre-computation needs to happen on the CTORs (not > sure if I remember that correctly) > 3) not sure if the patch allowed non-uniform CTORs but accesses to a > uniform subrange I must say I don't understand 1), because that is something the patch does, extract_range_from_load called from extract_range_from_assignment (now in vr-values.cc) during propagation as well as from simplify_stmt_using_range (at the end). For 2), the patch indeed wouldn't handle CTORs with RANGE_EXPRs efficiently, because I wanted to reuse as much as possible existing code (fold_const_aggregate_ref_1 in this case), instead of writing it again (but it would only try at most the param loads). Maybe handle two cases, one as the patch does with param limited check of arbitrary CTOR loads and another one that would only trigger with CTOR exactly matching the COMPONENT_REFs/ARRAY_REFs and in that case handle RANGE_EXPRs efficiently. 3) the patch didn't care what exactly is in the CTOR, so it would handle non-uniform CTORs, the restriction was that among the COMPONENT_REFs there is exactly one ARRAY_REF with SSA_NAME index and for this index it would use the value range of that SSA_NAME, plus get_nonzero_bits to figure out which constant indexes it needs to check in that range. I guess if needed it could be extended to handle some small constant number of SSA_NAME indexes instead of exactly one, but again as long as the product of the number of loads would be below the param.
