https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68576
--- Comment #7 from majun ---
(In reply to bin.cheng from comment #5)
> The type conversion comses from lim, below code:
> /* In case this is a stmt that is not unconditionally executed
> when the target loop header is executed and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68576
--- Comment #6 from bin.cheng ---
Hmm, at least for this case, lim should be aware that lim candidate doesn't
invoke undefined overflow when it is not executed after entering target loop.
Thus we don't need to rewrite it in unsigned arithmetic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68576
--- Comment #5 from bin.cheng ---
The type conversion comses from lim, below code:
/* In case this is a stmt that is not unconditionally executed
when the target loop header is executed and the stmt may
invoke undefined in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68576
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68576
--- Comment #3 from majun ---
(In reply to Richard Biener from comment #2)
> I think the issue is that with respect to loop 4 the evolution is
>
> _76 = { 1 + _373, + , 1 }_4
>
> but with all the casting we end up with
>
> (set_scalar_evolutio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68576
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68576
--- Comment #1 from majun ---
Sorry forget the command.
The example is compiled with
gcc -S -msse4.2 -ftree-parallelize-loops=4 -fdump-tree-parloops-details -O3
interchange-2.f -o interchange-2.s
