[Bug tree-optimization/113831] [11/12/13/14 Regression] Wrong VN with structurally identical ref since r9-398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113831 --- Comment #6 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:938a419182f8c43bd1212ffb98f8aa6077cf8326 commit r14-8929-g938a419182f8c43bd1212ffb98f8aa6077cf8326 Author: Richard Biener Date: Fri Feb 9 10:16:38 2024 +0100 tree-optimization/113831 - wrong VN with structurally identical ref When we use get_ref_base_and_extent during VN and that ends up using global ranges to restrict the range of a ref we have to take care of not using the same expression in the hashtable as for a ref that could not use that global range. The following attempts to ensure this by applying similar logic as get_ref_base_and_extent to copy_reference_ops_from_ref so they behave consistent. PR tree-optimization/113831 PR tree-optimization/108355 * tree-ssa-sccvn.cc (copy_reference_ops_from_ref): When we see variable array indices and get_ref_base_and_extent can resolve those to constants fix up the ops to constants as well. (ao_ref_init_from_vn_reference): Use 'off' member for ARRAY_REF and ARRAY_RANGE_REF instead of recomputing it. (valueize_refs_1): Also fixup 'off' of ARRAY_RANGE_REF. * gcc.dg/torture/pr113831.c: New testcase. * gcc.dg/tree-ssa/ssa-fre-104.c: Likewise.
[Bug tree-optimization/113831] [11/12/13/14 Regression] Wrong VN with structurally identical ref since r9-398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113831 --- Comment #5 from Richard Biener --- 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.
[Bug tree-optimization/113831] [11/12/13/14 Regression] Wrong VN with structurally identical ref since r9-398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113831 Richard Biener changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=108355 --- Comment #4 from Richard Biener --- The related bug might be also fixed then.
[Bug tree-optimization/113831] [11/12/13/14 Regression] Wrong VN with structurally identical ref since r9-398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113831 Jakub Jelinek changed: What|Removed |Added Summary|[11/12/13/14 Regression]|[11/12/13/14 Regression] |Wrong VN with structurally |Wrong VN with structurally |identical ref since |identical ref since r9-398 |r9-398-g6b9fc1782effc67dd9f | |6def16207653d79647553 | CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Shortening the summary. Started with r9-398-g6b9fc1782effc67dd9f6def16207653d79647553. Originally from PR113774.
[Bug tree-optimization/113831] [11/12/13/14 Regression] Wrong VN with structurally identical ref since r9-398-g6b9fc1782effc67dd9f6def16207653d79647553
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113831 --- Comment #2 from Richard Biener --- I think the issue is that we're using range info for get_ref_base_and_extent but we fail to do so when valueizing refs.
[Bug tree-optimization/113831] [11/12/13/14 Regression] Wrong VN with structurally identical ref since r9-398-g6b9fc1782effc67dd9f6def16207653d79647553
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113831 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Keywords||wrong-code Target Milestone|--- |11.5 Last reconfirmed||2024-02-08 --- Comment #1 from Richard Biener --- Mine.
