Message ID | alpine.LNX.2.00.1108301349360.2130@zhemvz.fhfr.qr |
---|---|
State | New |
Headers | show |
On Tue, 30 Aug 2011, Richard Guenther wrote: > > I've run into PR48571 again, and after having fun with out data-dep > analysis code I indeed believe that we should not try to re-construct > ARRAY_REFs from code involving pointer arithmetic. ARRAY_REFs > have constraints imposed on them that are relied on by data dependence > analysis and that are indeed useful to have (the index is within > bounds, otherwise undefined behavior). We can't recover from > lowering that happened, much as Zdenek argued when I initially > proposed to lower all ARRAY_REFs to pointer arithmetic with the > original MEM_REF design. > > Thus, the following completes the partial removal of reference > re-constructing I did when merging MEM_REFs (I removed the code > re-constructing COMPONENT_REFs back then). > > Not much fallout, much to my surprise (I've tried it initially > on the MEM_REF branch, but quickly gave up on this additional task). > We've appearantly become better in handling of pointer based accesses > (we've already much experience here with GFortran lowering > multi-dimensional array accesses to one-dimensional ones). > > The patch XFAILs one -Warray-bounds testcase, the -Warray-bounds > infrastructure needs some serious TLC which I didn't want to fold > into this patch. The testcase in question also really asks for > an 'access outside of object' warning, similar to the > 'offset outside bounds of constant string' one we have. > > Bootstrapped and tested an earlier version on x86_64-unknown-linux-gnu, > a final bootstrap and regtest cycle is currently running. > > (yes, there are still > tree-ssa-forwprop.c:forward_propagate_addr_into_variable_array_index and > fold-const.c:try_move_mult_to_index) Actually I forgot * gcc.dg/tree-ssa/ssa-ccp-25.c: Remove. * gcc.dg/tree-ssa/ssa-ccp-26.c: Likewise. which are feature tests for the reconstruction. Likewise I missed a recalculate_side_effects (*expr_p) in POINTER_PLUS_EXPR gimplification. With both fixed, bootstrapped and tested on x86_64-unknown-linxu-gnu and applied to trunk. Richard.
On Tue, Aug 30, 2011 at 4:59 AM, Richard Guenther <rguenther@suse.de> wrote: > > I've run into PR48571 again, and after having fun with out data-dep > analysis code I indeed believe that we should not try to re-construct > ARRAY_REFs from code involving pointer arithmetic. ARRAY_REFs > have constraints imposed on them that are relied on by data dependence > analysis and that are indeed useful to have (the index is within > bounds, otherwise undefined behavior). We can't recover from > lowering that happened, much as Zdenek argued when I initially > proposed to lower all ARRAY_REFs to pointer arithmetic with the > original MEM_REF design. > > Thus, the following completes the partial removal of reference > re-constructing I did when merging MEM_REFs (I removed the code > re-constructing COMPONENT_REFs back then). > > Not much fallout, much to my surprise (I've tried it initially > on the MEM_REF branch, but quickly gave up on this additional task). > We've appearantly become better in handling of pointer based accesses > (we've already much experience here with GFortran lowering > multi-dimensional array accesses to one-dimensional ones). > > The patch XFAILs one -Warray-bounds testcase, the -Warray-bounds > infrastructure needs some serious TLC which I didn't want to fold > into this patch. The testcase in question also really asks for > an 'access outside of object' warning, similar to the > 'offset outside bounds of constant string' one we have. > > Bootstrapped and tested an earlier version on x86_64-unknown-linux-gnu, > a final bootstrap and regtest cycle is currently running. > > (yes, there are still > tree-ssa-forwprop.c:forward_propagate_addr_into_variable_array_index and > fold-const.c:try_move_mult_to_index) > > Richard. > > 2011-08-30 Richard Guenther <rguenther@suse.de> > > PR middle-end/48571 > * gimple.h (maybe_fold_offset_to_address): Remove. > (maybe_fold_offset_to_reference): Likewise. > (maybe_fold_stmt_addition): Likewise. > (may_propagate_address_into_dereference): Likewise. > * tree-inline.c (remap_gimple_op_r): Do not reconstruct > array references. > * gimple-fold.c (canonicalize_constructor_val): Likewise. > Canonicalize invariant POINTER_PLUS_EXPRs to invariant MEM_REF > addresses instead. > (may_propagate_address_into_dereference): Remove. > (maybe_fold_offset_to_array_ref): Likewise. > (maybe_fold_offset_to_reference): Likewise. > (maybe_fold_offset_to_address): Likewise. > (maybe_fold_stmt_addition): Likewise. > (fold_gimple_assign): Do not reconstruct array references but > instead canonicalize invariant POINTER_PLUS_EXPRs to invariant > MEM_REF addresses. > (gimple_fold_stmt_to_constant_1): Likewise. > * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): Likewise. > * gimplify.c (gimplify_conversion): Likewise. > (gimplify_expr): Likewise. > > * gcc.c-torture/execute/pr48571-1.c: New testcase. > * gcc.dg/pr36902.c: XFAIL. > This caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50460
Index: gcc/testsuite/gcc.c-torture/execute/pr48571-1.c =================================================================== --- gcc/testsuite/gcc.c-torture/execute/pr48571-1.c (revision 0) +++ gcc/testsuite/gcc.c-torture/execute/pr48571-1.c (revision 0) @@ -0,0 +1,28 @@ +unsigned int c[624]; +void __attribute__((noinline)) +bar (void) +{ + unsigned int i; + /* Obfuscated c[i] = c[i-1] * 2. */ + for (i = 1; i < 624; ++i) + *(unsigned int *)((void *)c + (__SIZE_TYPE__)i * 4) + = 2 * *(unsigned int *)((void *)c + ((__SIZE_TYPE__)i + + ((__SIZE_TYPE__)-4)/4) * 4); +} +extern void abort (void); +int +main() +{ + unsigned int i, j; + for (i = 0; i < 624; ++i) + c[i] = 1; + bar(); + j = 1; + for (i = 0; i < 624; ++i) + { + if (c[i] != j) + abort (); + j = j * 2; + } + return 0; +}