at gcc dot |spop at gcc dot gnu.org
|gnu.org |
--- Comment #2 from Sebastian Pop 2011-02-04 07:56:18
UTC ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00277.html
||2011.02.04 07:57:49
AssignedTo|unassigned at gcc dot |spop at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #3 from Sebastian Pop 2011-02-04 07:57:49
UTC ---
Sure, I'll have a look.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46194
--- Comment #11 from Sebastian Pop 2011-02-05
01:39:23 UTC ---
Author: spop
Date: Sat Feb 5 01:39:20 2011
New Revision: 169847
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169847
Log:
Fix PR46194: fix the computation of distance vector
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46194
Sebastian Pop changed:
What|Removed |Added
Known to work||4.6.0
Known to fail|4.6.0
||2011.02.07 06:48:14
AssignedTo|unassigned at gcc dot |spop at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1 from Sebastian Pop 2011-02-07 06:48:14
UTC ---
The testcase contains a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46194
Sebastian Pop changed:
What|Removed |Added
Version|4.6.0 |4.5.4
Target Milestone|4.5.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46994
--- Comment #3 from Sebastian Pop 2011-02-08 16:54:03
UTC ---
Author: spop
Date: Tue Feb 8 16:53:57 2011
New Revision: 169928
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169928
Log:
Fix PRs 46834, 46994, and 46995: only rewrite reduct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46834
--- Comment #3 from Sebastian Pop 2011-02-08 16:54:04
UTC ---
Author: spop
Date: Tue Feb 8 16:53:57 2011
New Revision: 169928
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169928
Log:
Fix PRs 46834, 46994, and 46995: only rewrite reduct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46834
Sebastian Pop changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46995
--- Comment #3 from Sebastian Pop 2011-02-08 16:54:03
UTC ---
Author: spop
Date: Tue Feb 8 16:53:57 2011
New Revision: 169928
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169928
Log:
Fix PRs 46834, 46994, and 46995: only rewrite reduct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46994
Sebastian Pop changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46995
Sebastian Pop changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46886
--- Comment #5 from Sebastian Pop 2011-02-14 04:19:03
UTC ---
Patch:
http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00858.html
||2011.02.17 00:36:38
AssignedTo|unassigned at gcc dot |spop at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #2 from Sebastian Pop 2011-02-17 00:36:38
UTC ---
I do not think that 0001
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47653
Sebastian Pop changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #3 from Sebastian Po
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47653
--- Comment #4 from Sebastian Pop 2011-02-18 18:28:13
UTC ---
http://gcc.gnu.org/viewcvs?view=revision&revision=168211
removed all the uses of int_cst_value and replaced them with
tree_int_to_gmp, and here is what happens:
Breakpoint 5, scan_tre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47654
Sebastian Pop changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from Sebastian Po
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47654
--- Comment #5 from Sebastian Pop 2011-02-18 20:42:58
UTC ---
Created attachment 23400
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23400
first patch
This patch works around the bug by undoing the transform.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47848
--- Comment #1 from Sebastian Pop 2011-02-22 17:36:38
UTC ---
Author: spop
Date: Tue Feb 22 17:36:34 2011
New Revision: 170411
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=170411
Log:
Fix PR47848: Do not mention -ftree-loop-if-convert-m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47848
Sebastian Pop changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43654
Sebastian Pop changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54094
Sebastian Pop changed:
What|Removed |Added
CC||spop at gcc dot gnu.org
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47128
Sebastian Pop changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44303
Sebastian Pop changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51984
Sebastian Pop changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47089
Sebastian Pop changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48283
Sebastian Pop changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
||spop at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #2 from Sebastian Pop ---
gcc trunk does not depend on PPL and thus not depend on libgmpxx anymore.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43396
Sebastian Pop changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
--- Comment #18 from Sebastian Pop ---
On my laptop ARM Exynos5 at 1.6GHz I get this:
gfortran -ffast-math -O3 t.f90
./a.out
192.7510.2399826
gfortran -ffast-math -O3 -fgraphite -floop-interchange -floop-block
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
--- Comment #19 from Sebastian Pop ---
Default: tile_size = 32
gfortran -ffast-math -O3 -floop-nest-optimize t.f90 -v
./a.out
176.42500110.2399826
and then with a trivial patch that replaces that default constant 3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
--- Comment #20 from Sebastian Pop ---
-floop-nest-optimize does not have a cost model and so it blocks all loop
nests.
These two stmts are blocked:
A=0.1D0
B=0.1D0
This other stmt is not blocked:
C(I,J)=C(I,J)+A(I,K)*B(K,J)
The only thing we
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
--- Comment #21 from Sebastian Pop ---
Scop detection does not detect this loop because we now require the scev of the
data references to be analyzable in all the loops around:
commit e97c4b0daa932558eae4d9b9794cdd549e6d40bd
Author: rguenth
Date
||spop at gcc dot gnu.org
Resolution|FIXED |---
--- Comment #11 from Sebastian Pop ---
(In reply to Richard Biener from comment #8)
> There is a disconnect on how we analyze data-references during SCOP detection
> (outermost_loop is the root
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
--- Comment #22 from Sebastian Pop ---
Once we revert that patch, the remaining problem is that
graphite_can_represent_scev returns false on this scev:
{{(stride.12_14 + offset.13_15) + 1, +, stride.12_14}_1, +, 1}_2
the parameters are defined l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
--- Comment #23 from Sebastian Pop ---
If possible, we need to maintain the subscripted version of arrays:
C(I,J)
A(I,K)
B(K,J)
Without a representation of multi dimensional arrays, we would need to
delinearize the arrays prior to graphite.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
--- Comment #24 from Sebastian Pop ---
Looking at t.f90.003t.original (the first dump file of -fdump-tree-all-all)
I see that the array c is already in linear form:
(*cD.1876)[((integer(kind=8)D.9) jD.1897 * stride.12D.1892 + offset.13D.1893) +
(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
--- Comment #25 from Sebastian Pop ---
I think the linearization of array subscripts problem is linked to passing
arguments to a function in Fortran: by inlining the mult function call in the
main program, the main loop on C(I,J)=C(I,J)+A(I,K)*B(K
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
--- Comment #28 from Sebastian Pop ---
(In reply to Evgeniy Dushistov from comment #26)
> void mult(const double * const __restrict__ A, const double * const
> __restrict__ B, double * const __restrict__ C, const size_t N)
> {
> for (size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86865
Sebastian Pop changed:
What|Removed |Added
CC||spop at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87917
Sebastian Pop changed:
What|Removed |Added
CC||spop at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69545
Sebastian Pop changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |spop at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69545
Sebastian Pop changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Assignee: unassigned at gcc dot gnu.org
Reporter: spop at gcc dot gnu.org
Target Milestone: ---
$ cat h.c
float foo_p(float d, float min, float max, float a)
{
float tmin;
float tmax;
float inv = 1.0f / d;
if (inv >= 0) {
tmin = (min - a) * inv;
tmax = (max - a) *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70159
--- Comment #2 from Sebastian Pop ---
Right, with -Ofast it be able to optimize away the branch or selects.
The original benchmark had something more complex than fadd to use the tmin and
tmax results. Here is one more test using the results in a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70159
--- Comment #7 from Sebastian Pop ---
(In reply to Andrew Pinski from comment #6)
> Note this is both a hoisting and a sinking issue.
> Hoisting should happen before sinking.
> LLVM looks like it only implements sinking.
You are right: LLVM does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70159
--- Comment #9 from Sebastian Pop ---
Created attachment 37927
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37927&action=edit
patch for hoisting expressions
Updated the patch from PR23286 to hoist the redundant expressions:
:
inv_4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70956
--- Comment #2 from Sebastian Pop ---
The change looks good to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68823
--- Comment #15 from Sebastian Pop ---
> when DR_NUM_DIMENSIONS (dr1->dr) != DR_NUM_DIMENSIONS (dr2->dr) better "FAIL"?
Yes.
The patch looks good to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79622
--- Comment #4 from Sebastian Pop ---
Yes, that phi node looks like a reduction. We need to handle the phi as a
write to expose the loop carried reduction variable to the dependence analysis.
I think your change goes in the right direction. Tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69728
--- Comment #15 from Sebastian Pop ---
It makes sense to early fail when the schedule builder gets confused and built
an empty domain. Could you please also add a comment around the if that sets
schedule_error? The change looks good. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79622
--- Comment #8 from Sebastian Pop ---
> I would have expected at least each memory op to be in a separate "black box"
We could have a pass before graphite that splits BBs with more than one write
into blocks that contain one data write with all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69728
--- Comment #19 from Sebastian Pop ---
> So how'd we properly handle a valid empty domain?
DCE the statement.
If the domain for a statement is empty, it means that the statement does not
execute: it is dead code.
I think we are better enforcin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79622
--- Comment #10 from Sebastian Pop ---
> So a black-box would be a set of stmts rather than a whole GIMPLE BB
Correct: this can be an abstract view of the IR. The only place where we want
to start transforming the code is in the code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81373
--- Comment #4 from Sebastian Pop ---
The patch looks good. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69728
--- Comment #22 from Sebastian Pop ---
> I put it on my TODO to figure out how to "DCE" a stmt
> (or in this case it's rather the whole "loop body", right?).
The code generator would not even see a statement to be generated: it would
just disapp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79637
--- Comment #2 from Sebastian Pop ---
Here is what I see in doc/invoke.texi:
@item max-fsm-thread-path-insns
Maximum number of instructions to copy when duplicating blocks on a
finite state automaton jump thread path. The default is 100.
@item
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79637
--- Comment #3 from Sebastian Pop ---
As to why we call it a "finite state automaton" jump threading, that is because
this transform shows to be useful when the switch statement in the previous
example is contained in a loop, which is the way mos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65972
--- Comment #8 from Sebastian Pop ---
Yes please!
This patch also solves the problem I was chasing a week or so ago:
https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00067.html
I also know that this is ICE-ing on a large proprietary project when I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65972
--- Comment #9 from Sebastian Pop ---
In the link in the previous comment, Richi has a similar patch as suggested by
Dehao pending review/test/commit: let's close this bug when Richi's patch lands
in trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77362
--- Comment #7 from Sebastian Pop ---
The fix looks good. Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77362
--- Comment #8 from Sebastian Pop ---
LIM in general is bad for loop transforms: it introduces loop carried
dependences. If we can move graphite before LIM that would solve some problems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77362
--- Comment #10 from Sebastian Pop ---
(In reply to Richard Biener from comment #9)
> Yeah, but the user can write such dependences himself so ideally we have
> a way to undo them, like by using local scratch memory? So
You are right. LLVM-Pol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68823
--- Comment #4 from Sebastian Pop ---
The data dependence relations are dumped in the output of
-fdump-tree-graphite-all.
graphite-dependences.c contains the code for the data dependence computations.
Looking at the gimple code it seems like a tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68823
--- Comment #7 from Sebastian Pop ---
(In reply to Martin Liška from comment #5)
> Created attachment 40662 [details]
> Isolated graphite dump for miscompiled function
>
> As shown in the dump file, there are dependencies for the problematic stm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68823
--- Comment #8 from Sebastian Pop ---
The code in fault is called from pdr_add_memory_accesses()
Maybe the problem is in parsing the gimple MEM[] into a data reference.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68823
--- Comment #9 from Sebastian Pop ---
/* Determines the base object and the list of indices of memory reference
DR, analyzed in LOOP and instantiated in loop nest NEST. */
static void
dr_analyze_indices (struct data_reference *dr, loop_p nes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68823
--- Comment #11 from Sebastian Pop ---
(In reply to Richard Biener from comment #10)
> But then with different number of subscripts (and also likely different
> DR_BASE_OBJECT) you can't do anything with them and have to assume
> dependence. See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69675
--- Comment #10 from Sebastian Pop ---
(In reply to Richard Biener from comment #9)
> Yeah, seems to be gone with ISL 0.18 here as well... (but with 0.16.1 I can
> still reproduce it). ISL 0.18 doesn't do anything to the loop. ISL 0.16.1
> just
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82449
--- Comment #2 from Sebastian Pop ---
This part is not affine: {0, +, {1, +, 1}_1}_1
This is a polynomial of degree 2.
Are you sure the scev analysis reports this as affine?
I was trying to understand from the fortran code which part this scev c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77605
--- Comment #6 from Sebastian Pop ---
The proposed change looks good to me.
"last_conflicts" is the max index in the conflicting functions for which there
is a dependence:
mem_access_a (conflicting_iterations_in_a (last_conflicts)) is in depend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65177
--- Comment #9 from Sebastian Pop ---
I added a pass of update_ssa after each invocation of the SEME copier, and that
produced 26 extra fails (on top of the failing test) in the hmmer make check.
The problem with adding an update_ssa is that we h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65177
--- Comment #10 from Sebastian Pop ---
Created attachment 35005
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35005&action=edit
add update_ssa to seme copier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65177
--- Comment #12 from Sebastian Pop ---
(In reply to Jeffrey A. Law from comment #11)
> That is unless the SEME copier tries to update SSA internally, but that's
> painful.
I have also tried to update the SSA only in the copied basic blocks: grap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65177
--- Comment #14 from Sebastian Pop ---
(In reply to Jeffrey A. Law from comment #13)
> But you can need updates that extend beyond the scope of the SEME I would
> think. That was my recollection from looking at ways to minimize the number
> of b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65177
--- Comment #16 from Sebastian Pop ---
Created attachment 35030
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35030&action=edit
IR before and after for failing FSM jump thread
After updating the sources of GCC, I now see the fail as Jakub
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65177
--- Comment #17 from Sebastian Pop ---
Trying to figure out why we FSM jump thread this path: (13, 53) (53, 55) (55,
64) (64, 66) (66, 67) (67, 68) (68, 69) (69, 95) (95, 94) (94, 5) (94,
5)
In BB_94 we have this code:
switch (spr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65177
Sebastian Pop changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65177
--- Comment #20 from Sebastian Pop ---
Created attachment 35046
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35046&action=edit
fix
The attached patch fixes the problem by not creating diamonds in the copied
jump-thread.
I'm bootstrappin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65177
--- Comment #22 from Sebastian Pop ---
(In reply to Jeffrey A. Law from comment #21)
> Isn't the real issue here that the test for redirecting the edge is wrong?
You are right, the test for redirecting edges in copy_bbs is not sufficient for
jum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65177
--- Comment #23 from Sebastian Pop ---
Author: spop
Date: Wed Mar 25 22:49:47 2015
New Revision: 221675
URL: https://gcc.gnu.org/viewcvs?rev=221675&root=gcc&view=rev
Log:
diamonds are not valid execution threads for jump threading
PR tree-o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65177
Sebastian Pop changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46029
--- Comment #5 from Sebastian Pop ---
Maybe the patch was not committed because it was not ready before stage3:
"GCC 4.6 Stage 3 (starts 2010-11-03)". I will update the patch and resubmit
for review.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65972
Sebastian Pop changed:
What|Removed |Added
CC||dehao at gcc dot gnu.org,
Assignee: hubicka at gcc dot gnu.org
Reporter: spop at gcc dot gnu.org
CC: dehao at gcc dot gnu.org, hiraditya at msn dot com
Target Milestone: ---
lto1: internal compiler error: in compute_working_sets, at gcov-io.c:1006
0x790dad compute_working_sets(gcov_ctr_summary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
--- Comment #29 from Sebastian Pop ---
(In reply to Sebastian Pop from comment #28)
> delinearize the array accesses, and we don't have code to do that yet.
There is code to delinearize array accesses in LLVM now: it works on top of
SCEV, so it s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53852
--- Comment #19 from Sebastian Pop ---
Patch fixing the compile time problem with at least isl-0.15:
https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00198.html
isl-0.12 does not support the compute-out mechanism.
||spop at gcc dot gnu.org
Resolution|--- |FIXED
--- Comment #6 from Sebastian Pop ---
Fixed in r227567.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53852
Sebastian Pop changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59859
Bug 59859 depends on bug 53852, which changed state.
Bug 53852 Summary: [4.9/5/6 Regression] -ftree-loop-linear: large compile time
/ memory usage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53852
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
--- Comment #34 from Sebastian Pop ---
r227567 extends the limits of a scop, and now we can detect a scop in the
MAIN__ function corresponding to the following code:
A=0.1D0
B=0.1D0
-fdump-tree-graphite-all shows that the loops have been ti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
--- Comment #37 from Sebastian Pop ---
I think gcc should stop blocking initialization loops: it should only block a
loop when it contains more than two arrays, one array accessing non-contiguous
elements in memory, and another array accessing co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67700
--- Comment #2 from Sebastian Pop ---
Author: spop
Date: Mon Sep 28 17:29:59 2015
New Revision: 228214
URL: https://gcc.gnu.org/viewcvs?rev=228214&root=gcc&view=rev
Log:
fix PR67700
The patch makes the detection of scop parameters in parameter_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67700
Sebastian Pop changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67754
Sebastian Pop changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |spop at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67754
--- Comment #2 from Sebastian Pop ---
We diffed the output of -fdump-tree-graphite-all for interchange-1.c and the
problem seems to be related to the ISL scheduler: I would highly recommend that
people stop using outdated ISL versions.
with ISL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67754
--- Comment #4 from Sebastian Pop ---
The release managers will decide the requirements and when lib versions will be
deprecated.
I am still investigating a fix to continue supporting ISL-0.14: we will add
code to configure.ac to detect ISL vers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67754
--- Comment #5 from Sebastian Pop ---
Author: spop
Date: Tue Sep 29 22:15:08 2015
New Revision: 228268
URL: https://gcc.gnu.org/viewcvs?rev=228268&root=gcc&view=rev
Log:
use MIN fusion for ISL-14
This patch fixes PR66754 by reverting an earlier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67754
Sebastian Pop changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67754
Sebastian Pop changed:
What|Removed |Added
Status|RESOLVED|ASSIGNED
Last reconfirmed|
101 - 200 of 502 matches
Mail list logo
