http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59121
--- Comment #17 from Mircea Namolaru ---
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55022
Mircea Namolaru changed:
What|Removed |Added
CC||mircea.namolaru at inria dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59121
--- Comment #19 from Mircea Namolaru ---
The problem for many of these simple cases is with Graphite formulation of
memory accesses constraints. For Fortran, or C (if arrays are declared as
pointers), a memory access is not constrained enough (ba
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59586
Mircea Namolaru changed:
What|Removed |Added
CC||mircea.namolaru at inria dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55022
--- Comment #27 from Mircea Namolaru ---
Hi,
Many thanks.
I've passed over the meta-bug opened by you for Graphite,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859 and seems to me
that many of the problem have been already solved (some by you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60997
--- Comment #3 from Mircea Namolaru ---
It is not that -floop-interchange is disabled, but the code received by
graphite is different if the option -fopenmp is enabled. In this case the check
for data
dependencies required by loop-interchange fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61000
--- Comment #1 from Mircea Namolaru ---
The built-in heuristics assess that loop interchange is not profitable. Indeed
there is a problem, I would expected that the second loop to be found
profitable.
Need to look more in depth at this.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61000
--- Comment #2 from Mircea Namolaru ---
Again, the problem is due to representation of arrays in Fortran as array with
a single dimnesion (for similar code in C profitability check work as
expected). It is a recurring problem that may lead to comp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61000
--- Comment #4 from Mircea Namolaru ---
Right, C arrays expressed as pointers suffers from the same problem.
But for C at least there is a way to avoid this.
Many thanks for your suggestion of how to de-linearize arrays in middle-end, it
seems t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59121
Mircea Namolaru changed:
What|Removed |Added
CC||mircea.namolaru at inria dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59121
--- Comment #14 from Mircea Namolaru ---
Confirmed.
Start looking at it. This test also enters in an endless loop with the
options -fgraphite-identiy -floop-nest-optimize -O2 -c.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630
Mircea Namolaru changed:
What|Removed |Added
CC||mircea.namolaru at inria dot fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630
--- Comment #10 from Mircea Namolaru ---
On my Intel x86-64 platform changed in graphite-isl-ast-to-gimple.c:
- static int graphite_expression_type_precision = 128 <= max_mode_int_precision
?
- 128 : max_mode_int_precisi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630
--- Comment #14 from Mircea Namolaru ---
It seems to me that scalar evolution succeeds to determine
the number of iterations for the case of signed longs. Looking
in vectorization dump, first a symbolic expression for the number of
iterations of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630
--- Comment #16 from Mircea Namolaru ---
Yes, but it seems to me that the cast (not in the original code) should not
be generated at all if it could not be guaranteed that the casted-to type is
larger
enough to accommodate it. Otherwise you intr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630
--- Comment #18 from Mircea Namolaru ---
I've succeeded to explain why these casts are generated, and they seem correct.
Graphite introduces new induction variables with a larger size type (then the
type of original
induction variable), to make s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56145
Mircea Namolaru changed:
What|Removed |Added
CC||mircea.namolaru at inria dot fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56145
--- Comment #16 from Mircea Namolaru ---
Right, the NULL check fixed this for previous versions of GCC.
For the current version, it works without these NULL checks (the NULL paths are
not followed). The relevant scop fields are always initialize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64098
--- Comment #1 from Mircea Namolaru ---
Bug confirmed. The error message points to a problem in the way in which the
unroll-and-jam code manage the isl objects (the space is not freed properly).
I pinned down the function causing the problem,
19 matches
Mail list logo
