Meta-bug to track (still) missed optimizations in tramp3d-v4 testcase and so in FreePOOMA library using code. Full tramp3d-v4 can be fetched from http://www.tat.physik.uni-tuebingen.de/~rguenth/gcc/tramp3d-v4.cpp.gz attached is a reduced testcase (compile-time only), which instantiates one of the expression kernels representative for the application. Look at ;; Function void MultiArgKernel<MultiArg, Function>::run() [with MultiArg = Mult iArg2<Field<UniformRectilinearMesh<MeshTraits<3, double, UniformRectilinearTag, CartesianTag, 3> >, double, BrickViewU>, Field<UniformRectilinearMesh<MeshTraits <3, double, UniformRectilinearTag, CartesianTag, 3> >, double, BrickViewU> >, Fu nction = EvaluateLocLoop<Adv5::Ekin<3>, 3>] (_ZN14MultiArgKernelI9MultiArg2I5Fie ldI22UniformRectilinearMeshI10MeshTraitsILi3Ed21UniformRectilinearTag12Cartesian TagLi3EEEd10BrickViewUES9_E15EvaluateLocLoopIN4Adv54EkinILi3EEELi3EEE3runEv) preferably compile with "-O2 -Dleafify=flatten".
Created attachment 9279 [details] reduced compile-time testcase testcase
One easy to locate problem (and possibly the one blocking other optimizers like IVOPTs do anything useful) is aliasing. From the .vars dump we can see <L2>:; D.215486.D.81558.D.81253.domain_m[0].D.80426.D.50706.D.50587.domain_m = i0.4405; D.215486.D.81558.D.81253.domain_m[1].D.80426.D.50706.D.50587.domain_m = i1.4406; D.215486.D.81558.D.81253.domain_m[2].D.80426.D.50706.D.50587.domain_m = i2; D.215914 = D.215486.D.81558.D.81253.domain_m[0].D.80426.D.50706.D.50587.domain_m; D.215816 = D.215486.D.81558.D.81253.domain_m[1].D.80426.D.50706.D.50587.domain_m; D.215629 = *(D.215772 + (double *) ((unsigned int) (D.215808 + D.215914 + D.215816 * D.215806) * 8)); The structure containing an 3-dimensional index into an array D.215486 is assigned from the integer variables i0, i1, i2 which control a three-level nested loops. You can see easily that in the inner loop (whose head you can see) operations on indices i1 and i2 are not hoisted out of the loop because aliasing thinks the stores to the structure alias. Which also causes us not to propagate the assignments from i0, i1, i2 to the final use in the memory access.
Subject: Bug 22501 Author: rguenth Date: Wed Nov 30 20:55:41 2005 New Revision: 107737 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107737 Log: 2005-11-30 Richard Guenther <rguenther@suse.de> PR tree-optimization/22501 * tree-ssa-forwprop.c (forward_propagate_addr_expr_1): New function split out from ... (forward_propagate_addr_expr): ... here. Use it to propagate ADDR_EXPRs to all uses. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-forwprop.c
Subject: Bug 22501 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
PR 19431 shows up in tramp3d.
Do we still need this given that all PRs are fixed? Or shall we attach more bugs here, like the compile time/unrolling before inlining and other issues?
No, let's just close this.