The following code causes gcc trunk (and the 4.7 & 4.8 branches) to hang at -O1 or above. This seems to be different from 57381, but perhaps related. $ gcc-trunk -v Target: x86_64-unknown-linux-gnu gcc version 4.9.0 20130525 (experimental) [trunk revision 199323] (GCC) $ gcc-trunk -m32 -O0 -c small.c $ gcc-trunk -m32 -O1 -c small.c ^C $ cat small.c int a, b, c; void foo () { volatile int d[1]; b = 0; for (;; a--) c = (int)&d[b]; }
Yeah, similar. Mine.
The existing support for comparing addresses in operand_equal_p cannot handle this as the volatile array is local. It seems to me that there is no good reason to ever treat addresses of TREE_SIDE_EFFECTS trees as different if there is not TREE_SIDE_EFFECTS on offset determining pieces (though that would rely on gimplification for COMPONENT_REFs?). I wonder if this is the right time to introduce gimple_op_equal_p (), wrapping operand_equal_p but handling a few cases less conservative...
Created attachment 30202 [details] prototype patch Like the attached.
> It seems to me that there is no good reason to ever treat addresses of > TREE_SIDE_EFFECTS trees as different if there is not TREE_SIDE_EFFECTS > on offset determining pieces (though that would rely on gimplification > for COMPONENT_REFs?). Yes, I agree that the handling of addresses looks overly conservative.
On Mon, 27 May 2013, ebotcazou at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57417 > > --- Comment #4 from Eric Botcazou <ebotcazou at gcc dot gnu.org> --- > > It seems to me that there is no good reason to ever treat addresses of > > TREE_SIDE_EFFECTS trees as different if there is not TREE_SIDE_EFFECTS > > on offset determining pieces (though that would rely on gimplification > > for COMPONENT_REFs?). > > Yes, I agree that the handling of addresses looks overly conservative. I suppose TREE_SIDE_EFFECTS matter on the offset expression of a get_inner_reference call on op0 of the ADDR_EXPR. For Ada that would involve looking at SUBSTITUTE_PLACEHOLDER_IN_EXPR (DECL_FIELD_OFFSET (field), exp) for example - or do we somehow guarantee that the offset expressions that do not appear in indexes like operand 1 of ARRAY_REFs do not contain side-effects?
Author: rguenth Date: Mon May 27 12:44:29 2013 New Revision: 199356 URL: http://gcc.gnu.org/viewcvs?rev=199356&root=gcc&view=rev Log: 2013-05-27 Richard Biener <rguenther@suse.de> Revert PR middle-end/57381 * fold-const.c (operand_equal_p): Compare FIELD_DECLs with OEP_CONSTANT_ADDRESS_OF retained. PR tree-optimization/57417 * tree-ssa-sccvn.c (vn_reference_fold_indirect): Fix test for unchanged base. (set_ssa_val_to): Compare addresses using get_addr_base_and_unit_offset. * gcc.dg/torture/pr57417.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr57417.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c
> I suppose TREE_SIDE_EFFECTS matter on the offset expression of > a get_inner_reference call on op0 of the ADDR_EXPR. For Ada that > would involve looking at SUBSTITUTE_PLACEHOLDER_IN_EXPR (DECL_FIELD_OFFSET > (field), exp) for example - or do we somehow guarantee that the > offset expressions that do not appear in indexes like operand 1 of > ARRAY_REFs do not contain side-effects? No, we cannot guarantee that. But AFAICS operand_equal_p rejects two ADDR_EXPRs of the same expression when !OEP_ONLY_CONST only because it has TREE_SIDE_EFFECTS and I don't see why, IOW my understanding is that it should be possible to add a OEP_ADDRESS_OF flag when !OEP_ONLY_CONST and use it to be less conservative.
Author: jakub Date: Thu Aug 29 13:14:59 2013 New Revision: 202074 URL: http://gcc.gnu.org/viewcvs?rev=202074&root=gcc&view=rev Log: Backported from mainline 2013-07-22 Georg-Johann Lay <avr@gjlay.de> PR testsuite/52641 * gcc.dg/torture/pr57381.c: Add dg-require-effective-target int32plus. 2013-05-27 Richard Biener <rguenther@suse.de> PR middle-end/57381 PR tree-optimization/57417 * tree-ssa-sccvn.c (vn_reference_fold_indirect): Fix test for unchanged base. (set_ssa_val_to): Compare addresses using get_addr_base_and_unit_offset. PR tree-optimization/57417 * gcc.dg/torture/pr57417.c: New testcase. 2013-05-23 Richard Biener <rguenther@suse.de> PR middle-end/57381 * gcc.dg/torture/pr57381.c: New testcase. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr57381.c branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr57417.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-ssa-sccvn.c
Fixed for 4.8.2+.
Author: rguenth Date: Tue May 6 14:22:41 2014 New Revision: 210110 URL: http://gcc.gnu.org/viewcvs?rev=210110&root=gcc&view=rev Log: 2014-05-06 Richard Biener <rguenther@suse.de> Backport from mainline 2013-05-27 Richard Biener <rguenther@suse.de> PR tree-optimization/57417 * tree-ssa-sccvn.c (set_ssa_val_to): Compare addresses using get_addr_base_and_unit_offset. * gcc.dg/torture/pr57417.c: New testcase. Added: branches/gcc-4_7-branch/gcc/testsuite/gcc.dg/torture/pr57417.c Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/gcc/tree-ssa-sccvn.c
Fixed.