[Bug tree-optimization/55022] [4.8 Regression] air.f90 is miscompliled with -m64 -O2 -fgraphite-identity after revision 190619
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55022 --- Comment #7 from Tobias Grosser 2013-02-05 16:10:21 UTC --- (In reply to comment #5) > I'll take a peek. Wonderful, feel free to CC me if you have any questions!
[Bug tree-optimization/54094] ICE in graphite-dependences.c:320 : isl_constraint.c:497: position out of bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54094 Tobias Grosser changed: What|Removed |Added Status|NEW |RESOLVED CC||grosser at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Tobias Grosser --- Fixed with: Author: grosser Date: Sun Jul 14 06:45:08 2013 + graphite: Do not depend on 2D + 1 form in parallelism check PR tree-optimization/54094 * graphite-clast-to-gimple.c (translate_clast_for_loop): Derive the scheduling dimension for the parallelism check from the polyhedral information in the AST. * graphite-dependences.c (carries_deps): Do not assume the schedule is in 2D + 1 form. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@200946
[Bug tree-optimization/50561] [4.7 regression] ICE when compiling zlib with -O2 -floop-flatten -floop-strip-mine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50561 --- Comment #7 from Tobias Grosser 2012-02-08 15:38:19 UTC --- Created attachment 26614 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26614 A possible fix Here a possible fix. The commit message is: Removing old scattering dimensions after loop flattening is incorrect. As long as we use PPL we are not able to remove the old scattering dimensions. The reason is that these dimensions are not entirely unused. They are not necessary as part of the scheduling vector, as the earlier dimensions already unambiguously define the execution time, however they may still be needed to carry modulo constraints as introduced e.g. by strip mining. The correct solution would be to project these dimensions out of the scattering polyhedra. In case they are still required to carry modulo constraints they should be kept internally as existentially quantified dimensions. PPL does only support projection of rational polyhedra, however in this case we need an integer projection. With isl this will be trivial to implement. For now we just leave the dimensions. This is a little ugly, but should be correct. Could you verify it it works for you?
[Bug tree-optimization/52275] The polyhedron test air.f90 is miscompiled with '-O2 -floop-flatten' after revision 184265
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52275 --- Comment #3 from Tobias Grosser 2012-02-16 14:00:29 UTC --- It seems there Sebastian himself sees the loop flatteing pass as currently unstable: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50335#c8 I would propose to follow his suggestion, disable it for now and readd it as soon as graphite is moved to isl. If anybody else can contribute a patch that fixes the remaining loop flattening problems, I am obviously glad to have a look,
[Bug testsuite/50023] FAIL: gcc.dg/graphite/id-pr46845.c (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50023 Tobias Grosser changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Tobias Grosser 2012-01-09 19:20:13 UTC --- (In reply to comment #2) > A patch has been submitted at > http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00611.html and approved at > http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00612.html . Any reason why it > has > not been committed? To me it seems it was committed 10.10.2011. Here the relevant commit: http://gcc.gnu.org/viewcvs?view=revision&revision=179762 Does this commit not show up for you? I marked this as resolved. If you cannot find the commit, please reopen the bug. All the best from ENS Paris Tobi
[Bug tree-optimization/59121] [4.8/4.9 Regression] endless loop with -O2 -floop-parallelize-all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59121 --- Comment #18 from Tobias Grosser --- (In reply to Mircea Namolaru from comment #17) > Yes, data dependencies computation is expensive in the polyehdral model > and it could take considerable time - but it is worrying that in too many > cases fails to provide (after a few hours left running, when I stop it) an > answer for very simple programs. I will ckeck with the isl people if this is > the expected behaviour of the isl_union_map_compute_flow (this is the > function where the data dependency computation is stuck) and how (and if) > they could help us. I would like to state that data-dependence calculation is not inherently more complex in the polyhedral mode. In fact, any simple data-dependence test that exists could be implemented in our polyhedral checker to speed up the common case if really necessary. We did not do this, as for such simple cases the dependence analysis is normally very fast. In the general case, dependence solving is inherently complex (equivalent to ILP programming -> NP-complete), and we can not do better anyway. Though for the most cases of slowdown, we could probably do better. For this it is necessary to understand why a certain case is slow. Hence, it is important to look into the dependence problem we are trying to solve and see why we can not solve it quickly. The problem may be inherently complex, but there may also be a simple fix. > Many Fortran programs with loops having no-constants bounds and > n-dimensional arrays (n>=3) may be affected by this problem and may work > only for small > dimensions of the arrays. > The problem touches especially Fortran, that uses > linearized accesses to multi-dimensional arrays - this creates patterns > leading to this problem (in this example we have an array acc of dimension > 55,48,49 and the array access acc(j,k,l) is transformed to acc(j + 55*k + > 2640*l). So what exactly makes the problem difficult? Without understanding this, it is very difficult to predict in which situations the dependence analysis will be slow. > I've checked the constraints passed to isl_union_map_compute You mean isl_union_map_compute_flow() > - see that > wrapping is perfromed. But wrapping requires modulo operation, expressed by > constraints with existential quantifier that may be harder to solve. This is an interesting observation. Instead of modeling the modulo wrapping, we could assume it does not exist and just add a run-time check around the kernel that ensures that we only execute kernels where we know this is the case. > By > disabling the wrapping, some simple examples that before were stuck in data > dependency computation finish immediately. Nice. > In what measure is wrapping > necessary ? - as a side-effect it may increase compilation time (that may be > already considerable). In some cases additions/multiplications have defined the semantics in case of overflow as the computation being performed modulo the size of the type. This case rarely happens, but in case we want to be correct, we can not just ignore it. Cheers, Tobias
[Bug tree-optimization/58028] [4.9 Regression] Several failures in libgomp.graphite after revision 200946
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58028 --- Comment #9 from Tobias Grosser --- (In reply to rguent...@suse.de from comment #8) > On Wed, 29 Jan 2014, dominiq at lps dot ens.fr wrote: > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58028 > > > > --- Comment #7 from Dominique d'Humieres --- > > > The testsuite failures are. We have to do sth about them. > > > > Revert r200946? > > Probably - the > > + * graphite-dependences.c (carries_deps): Do not assume the > schedule is > + in 2D + 1 form. > > part looks wrong. > > - idx = 2 * depth + 1; > - for (i = 0; i < idx; i++) > + for (i = 0; i < depth - 1; i++) > > we now iterate over less dimensions than before. Only in cases where the schedule is not in 2D + 1 form. In case the schedule is in 2D + 1 form int scheduling_dim = isl_set_n_dim (domain); will be equal to 2 * depth + 1. > I'd say we should simply check whether the loop _is_ in 2D + 1 form > at > > + isl_set *domain = isl_set_from_cloog_domain (stmt->domain); > + int scheduling_dim = isl_set_n_dim (domain); > + >if (flag_loop_parallelize_all > - && loop_is_parallel_p (loop, bb_pbb_mapping, level)) > + && loop_is_parallel_p (loop, bb_pbb_mapping, scheduling_dim)) > loop->can_be_parallel = true; > > thus > >if (flag_loop_parallelize_all >&& scheduling_dim == 2 * level + 1 >&& loop_is_parallel_p (loop, bb_pbb_mapping, level) > loop->can_be_parallel = true; The change you propose seems conservatively correct, as in that loops that are not in 2D + 1 form are not detected to be parallel. This change may hide the bug, but I don't see any bug it solves. > no time to check whether reverting the other hunk plus this will > resolve the bug the revision fixed and restores the testcases. I assume it will fix the crash, but it will not detect parallellism in none 2D+1 loops, something the isl scheduler happily creates.
[Bug tree-optimization/58028] [4.9 Regression] Several failures in libgomp.graphite after revision 200946
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58028 Tobias Grosser changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #11 from Tobias Grosser --- Thanks Richi for starting to look into this. As posted in the other bug report Mircea, will be taking over the maintenance work with graphite, looking into this bug report with priority. I will be helping him to come to speed with graphite.
[Bug tree-optimization/59121] [4.8/4.9 Regression] endless loop with -O2 -floop-parallelize-all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59121 Tobias Grosser changed: What|Removed |Added CC||grosser at gcc dot gnu.org --- Comment #16 from Tobias Grosser --- (In reply to Jeffrey A. Law from comment #15) > Mircea, thanks. I'm definitely looking forward to seeing Graphite in a > better state! With you on board at INRIA and working on Graphite, I will > not be calling for Graphite's removal after the 4.9 release. > > Thanks again, > jeff This bug is probably the perfect case to use isl's new compute out facility, which allows us to give up after a certain number of compute iterations. This will give us the assurance that we do not hang any more in the graphite dependence analysis, but that we instead bail out smoothly. We should probably also work on the efficiency of the analysis (and there is a lot that could be done), but in my opinion the number one priority is that we avoid unpredictable compile time. After this issue is fixed, we can address cases where we bail out as missed optimizations. Something, that is a lot less intrusive.
[Bug bootstrap/61792] [4.10 Regression] Bootstrap error with undeclared function isl_ast_expr_get_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61792 --- Comment #11 from Tobias Grosser --- (In reply to Manfred Schwarb from comment #10) > Dominique, you are right. > The issue is not with isl-0.12 and isl-0.13. > > It is isl-0.11 that is missing these include files. So with the > above mentioned check-in, building GCC using isl-0.11 does no longer work. > > I just could build trunk successfully now, using isl-0.12.2. > > One should rip isl-0.11 support out of configure etc. therefore. > > > OK, I see what could have happened to Thomas: GMP support in isl > is optional. If you build isl without gmp headers being present, > then probably you wont get the needed headers to compile GCC. > So it seems isl-0.12.2 with GMP support is needed to build graphite. GMP support only became optional with the unreleased isl-0.14. graphite should build correctly with isl-0.12.2 and cloog-0.18.2. We should remove remove other versions from the configure check. Roman, is currently working on adapting configure.
