https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102131
--- Comment #4 from bin cheng ---
(In reply to Jiu Fu Guo from comment #3)
> The issue may come from 'iv0 cmp iv1' transform:
>
>if (c -->if (c>=b) in-loop
> -->if (b<=c) in-loop
>
> c: {4, +, 3}
> b: {1, +, 1}
>
> if ({1, +, 1} <=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101145
--- Comment #7 from bin cheng ---
(In reply to Jiu Fu Guo from comment #5)
> (In reply to bin cheng from comment #4)
> > (In reply to Jiu Fu Guo from comment #3)
> > > Yes, while the code in adjust_cond_for_loop_until_wrap seems somehow
> > > t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101145
--- Comment #4 from bin cheng ---
(In reply to Jiu Fu Guo from comment #3)
> Yes, while the code in adjust_cond_for_loop_until_wrap seems somehow tricky:
>
> /* Only support simple cases for the moment. */
> if (TREE_CODE (iv0->base) != IN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101145
--- Comment #2 from bin cheng ---
(In reply to Richard Biener from comment #1)
> This comes up with a pending patch to split loops like
>
> void
> foo (int *a, int *b, unsigned l, unsigned n)
> {
> while (++l != n)
> a[l] = b[l] + 1;
> }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101173
--- Comment #5 from bin cheng ---
(In reply to Richard Biener from comment #3)
> So we're exchanging the inner two loops
>
> a[1][3] = 8;
> for (int b = 1; b <= 5; b++)
> for (int d = 0; d <= 5; d++)
> for (c = 0; c <= 5; c++)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100740
bin cheng changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |amker at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #19 from bin cheng ---
(In reply to bin cheng from comment #18)
> Did some experiments, there are two fallouts after explicitly returning
> false for unsigned/wrapping types in MULT_EXPR/MINUS_EXPR/PLUS_EXPR. One is
> the mentioned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #18 from bin cheng ---
Did some experiments, there are two fallouts after explicitly returning false
for unsigned/wrapping types in MULT_EXPR/MINUS_EXPR/PLUS_EXPR. One is the
mentioned use of multiple_of_p in number_of_iterations_ne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #14 from bin cheng ---
(In reply to Richard Biener from comment #12)
> So in number_of_iterations_ne it looks like the step 's' is always constant
> which makes me wonder if we can somehow use ranger to tell multiple_of_p
> (type, c,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #13 from bin cheng ---
(In reply to Richard Biener from comment #10)
> (In reply to bin cheng from comment #9)
> > Seems we have a long standing bug in fold-const.c:multiple_of_p in case of
> > wrapping types. Take unsigned int as a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90078
--- Comment #19 from bin cheng ---
I will check if the latter fix can be easily backported to GCC-9.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
--- Comment #9 from bin cheng ---
Seems we have a long standing bug in fold-const.c:multiple_of_p in case of
wrapping types. Take unsigned int as an example:
(0xfffc * 0x3) % 0x3 = 0x1
But multiple_of_p returns true here.
The same issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100499
bin cheng changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |amker at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98736
--- Comment #6 from bin cheng ---
Shall this be backported to 10/11 later? Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95638
bin cheng changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98736
--- Comment #4 from bin cheng ---
(In reply to bin cheng from comment #3)
> hmm, seems topological order isn't enough for distributing a loop nest, we
> need topological order plus inner loop depth-first.
Well, not really. In this case, problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99067
--- Comment #3 from bin cheng ---
Though not sure if the underlying root causes are the same, I think these are
two different issues, at least, they are handled by different parts of code in
IVOPTs.
For the first one, it's a known issue in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98736
--- Comment #3 from bin cheng ---
hmm, seems topological order isn't enough for distributing a loop nest, we need
topological order plus inner loop depth-first.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99067
bin cheng changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |amker at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97627
--- Comment #12 from bin cheng ---
a. why the loop is considered as infinite
b. we need to skip fake exit edges in niter analysis?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97627
--- Comment #11 from bin cheng ---
(In reply to bin cheng from comment #10)
> hmm,
> For below basic block:
> 128 ;; basic block 4, loop depth 2, maybe hot
> 129 ;;prev block 3, next block 9, flags: (NEW, VISITED)
> 130 ;;pred: 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97627
--- Comment #10 from bin cheng ---
hmm,
For below basic block:
128 ;; basic block 4, loop depth 2, maybe hot
129 ;;prev block 3, next block 9, flags: (NEW, VISITED)
130 ;;pred: 3 (FALLTHRU,EXECUTABLE)
131 ;;7 (FALL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97627
--- Comment #9 from bin cheng ---
(In reply to Jakub Jelinek from comment #8)
> Still broken on current 10 branch, as written works fine on the trunk due to
> the C++ FE loop changes.
> Bin, did you have time to look into this yet?
I am very sor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98598
--- Comment #4 from bin cheng ---
Didn't go deep into the case.
For simple cases taken as examples, it's possible to interchange the two loops
thus enables loop invariant code motion. Though loop interchange may fail
because of complicated data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97627
--- Comment #5 from bin cheng ---
(In reply to Jakub Jelinek from comment #3)
> Started with r9-4145-ga81e2c6240655f60a49c16e0d8bbfd2ba40bba51
Sorry for the breakage. Will fix this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78427
bin cheng changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- Comment #5 from
26 matches
Mail list logo
