| Summary: | Aliasing can not tell array members apart | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Richard Biener <rguenth> |
| Component: | tree-optimization | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | gcc-bugs |
| Priority: | P2 | Keywords: | alias, missed-optimization |
| Version: | 4.1.0 | ||
| Target Milestone: | 4.2.0 | ||
| Host: | Target: | ||
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | 2005-11-26 00:52:04 | |
| Bug Depends on: | 22555 | ||
| Bug Blocks: | 22501 | ||
| Attachments: | patch fixing the problem | ||
Meanwhile I have a complete patch which survives bootstrap and regtesting. Also fixes 22555. In functionality it depends on it, though. Created attachment 9481 [details]
patch fixing the problem
Patch attached for reference.
Can you document what's the compile-time effect of raising salias-max-array- elements? For instance, how much do we lose in bootstrap+tramp3d if we raise it to 16 or even 1024? Subject: Re: Aliasing can not tell array members
apart
On 12 Aug 2005, giovannibajo at libero dot it wrote:
> Can you document what's the compile-time effect of raising salias-max-array-
> elements? For instance, how much do we lose in bootstrap+tramp3d if we raise it
> to 16 or even 1024?
I'll do so once I return from holidays.
Richard.
Ok, here are some numbers. Unpatched vs. patched with the default of 4 results in about 1% compile time increase for tramp3d-v4 while decreasing runtime by about 15%. Raising it to higher levels does not improve runtime, but, f.i. with 16 it takes a 2% compile-time hit. Times for building stage2 with 4/16 are not different, as are building stage3 with the built compiler. A good default number for Fortran would be so that it would be able to tell all members of array descriptors apart, for C/C++ 4 should be generally ok, though raising it to the Fortran default is an option. Specifically for GCC one could search for the largest in-struct array -- maybe the operands array in the tree structure. Subject: Bug 22548 Author: rguenth Date: Sat Jan 14 14:30:33 2006 New Revision: 109703 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109703 Log: 2006-01-14 Richard Guenther <rguenther@suse.de> PR tree-optimization/22548 PR tree-optimization/22555 PR tree-optimization/22501 * Makefile.in (tree-ssa-structalias.o): Depend on $(PARAMS_H). * params.def (salias-max-array-elements): New parameter. * params.h (SALIAS_MAX_ARRAY_ELEMENTS): Define. * doc/invoke.texi (salias-max-array-elements): Document. * tree-flow-inline.h (var_can_have_subvars): We also handle arrays now. * tree-ssa-alias.c (find_used_portions): Handle ARRAY_REF like COMPONENT_REF. * tree-ssa-structalias.c (params.h): Include. (push_fields_onto_fieldstack): Handle ARRAY_TYPE. (find_func_aliases): Handle multiple constraints from ARRAY_REF. (get_constraint_for): For ADDR_EXPR operating on something containing an ARRAY_REF, add all subvars to the solution. (handle_ptr_arith): Handle ARRAY_TYPE like RECORD_TYPE types. * tree-ssa-operands.c (parse_ssa_operands): Handle ARRAY_REF for creating MUST_DEFs. (get_expr_operands): Treat ARRAY_REF like COMPONENT_REF wrt subvars. * gcc.dg/tree-ssa/alias-4.c: New testcase. * gcc.dg/tree-ssa/alias-5.c: Likewise. * gcc.dg/tree-ssa/alias-6.c: Likewise. * gcc.dg/tree-ssa/alias-7.c: Likewise. * gcc.dg/tree-ssa/alias-8.c: Likewise. * gcc.dg/tree-ssa/alias-9.c: Likewise. * gcc.dg/tree-ssa/alias-10.c: Likewise. * gcc.dg/tree-ssa/alias-11.c: Likewise. * gcc.dg/tree-ssa/alias-12.c: Likewise. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/alias-10.c trunk/gcc/testsuite/gcc.dg/tree-ssa/alias-11.c trunk/gcc/testsuite/gcc.dg/tree-ssa/alias-12.c trunk/gcc/testsuite/gcc.dg/tree-ssa/alias-4.c trunk/gcc/testsuite/gcc.dg/tree-ssa/alias-5.c trunk/gcc/testsuite/gcc.dg/tree-ssa/alias-6.c trunk/gcc/testsuite/gcc.dg/tree-ssa/alias-7.c trunk/gcc/testsuite/gcc.dg/tree-ssa/alias-8.c trunk/gcc/testsuite/gcc.dg/tree-ssa/alias-9.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/doc/invoke.texi trunk/gcc/params.def trunk/gcc/params.h trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-flow-inline.h trunk/gcc/tree-ssa-alias.c trunk/gcc/tree-ssa-operands.c trunk/gcc/tree-ssa-structalias.c Fixed. |
For the following testcase (s is global so SRA cannot decompose it), aliasing can not tell that the store to s.i[1] does not alias s.i[0]. So instead of optimizing this to return 3; at the tree-level, we do a load of s.i[0]. struct { int i[2]; } s; int foo(void) { s.i[0] = 1; s.i[1] = 2; return s.i[0] + s.i[1]; } Note that it cannot even do this if you remove the wrapping structure, though you won't find many instances of such in C++ code. But at least for this I'd have a patch, if not IVOPTs would suck so much wrt aliasing.