https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113831
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> --- So we have equal vn_reference but with different ao_ref. Note the recorded vn_reference has value-numbers in operands (not sanitized via AVAIL to a specific location) but the ao_ref is eventually initialized from get_ref_base_and_extent on the original ref which can use context sensitive info. That doesn't actually compute a constant array index from a variable one but instead it constrains the extend of the access which eventually gets to max_size == size. To apply the same logic consistently to the VN representation (which is eventually valueized) we can only look at ranges on names either from the original ref (during copy_reference_ops_from_ref) or when valueizing with AVAIL in mind. For consistency operating from copy_reference_ops_from_ref would be preferred. It's going to be quite sophisticated to reverse-engineer all constant array indexes from the overall [offset, offset + size] computed by get_ref_base_and_extent (we definitely want to do that only once per copy_reference_ops_from_ref). For PRE we do need all the components, so we have to somehow post-process the vn_reference ops. The other possibility for a fix would be to try to fend off ranges being used by get_ref_base_and_extent (but only for the calls on the refs we're going to insert into the expression hash table). get_range_query cannot be tricked so it would be an extra arg to get_ref_base_and_extent and possibly ao_ref_init. That sounds a bit ugly. I will try to implement the post-processing.
