--- Comment #4 from irar at il dot ibm dot com 2008-04-24 12:24 ---
(In reply to comment #2)
>
> the final increment for ivtmp.15_36 is wrong -- it should be 48.
>
Right. We are not supposed to vectorize this at all, since SLP currently
doesn't support loads with ga
--- Comment #3 from irar at il dot ibm dot com 2008-05-04 05:54 ---
(In reply to comment #1)
>
> SLP also doesn't handle vectorization of register operations but needs
> memory source and destination operands(?).
Right.
> Likewise SLP shouldn't be
> confus
--- Comment #4 from irar at il dot ibm dot com 2008-05-04 06:02 ---
(In reply to comment #2)
> The vectorizer doesn't know to vectorize __builtin_cexpi or
> {REAL,IMAG}PART_EXPR
> either.
>
> IMHO rather than somehow tweaking the early unroller the vectorizer shoul
--- Comment #1 from irar at il dot ibm dot com 2008-05-04 08:00 ---
I don't get the ICE: revision 134926, x86_64-linux, same flags. The loop in
line 14 gets vectorized.
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36119
--- Comment #3 from irar at il dot ibm dot com 2008-05-04 11:13 ---
In my dump this stmt is vectorized ok:
bug.F:14: note: -->vectorizing statement: D.1055_23 = ((D.1054_22))
bug.F:14: note: transform statement.
bug.F:14: note: vect_is_simple_use: operand ((D.1054_22))
bug.F
--- Comment #4 from irar at il dot ibm dot com 2008-05-04 11:21 ---
If it is really a try to SLP, I think this patch will fix the ICE:
Index: tree-vect-transform.c
===
--- tree-vect-transform.c (revision 134926
--- Comment #6 from irar at il dot ibm dot com 2008-05-04 11:49 ---
(In reply to comment #5)
> Created an attachment (id=15574)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15574&action=view) [edit]
> vectorizer dump
>
> Attached.
Thanks!
> The last li
--- Comment #8 from irar at il dot ibm dot com 2008-05-04 12:07 ---
(In reply to comment #7)
> It does - and the loop is vectorized. But it looks like a hack ;)
It is not. We actually do this in all vectorizable_...() that support SLP.
SLP currently does not support multiple types
--- Comment #10 from irar at il dot ibm dot com 2008-05-04 12:26 ---
(In reply to comment #9)
> Can you give the patch bootstrap & test? I'll pre-approve
> it here.
Sure, for both trunk and 4.3.1, I guess.
Ira
>
> Thanks,
> Richard.
>
--
--- Comment #14 from irar at il dot ibm dot com 2008-05-12 12:17 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|NEW
--- Comment #4 from irar at il dot ibm dot com 2008-05-14 07:04 ---
It's a bug in SLP analysis. I am working on a fix.
Ira
--
irar at il dot ibm dot com changed:
What|Removed |
--- Comment #7 from irar at il dot ibm dot com 2008-05-14 12:30 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from irar at il dot ibm dot com 2008-05-22 05:41 ---
*** This bug has been marked as a duplicate of 35642 ***
--
irar at il dot ibm dot com changed:
What|Removed |Added
--- Comment #13 from irar at il dot ibm dot com 2008-05-22 05:41 ---
*** Bug 36295 has been marked as a duplicate of this bug. ***
--
irar at il dot ibm dot com changed:
What|Removed |Added
--- Comment #3 from irar at il dot ibm dot com 2008-05-22 10:48 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from irar at il dot ibm dot com 2008-06-11 08:00 ---
Reproduced on powerpc64-suse-linux.
Doesn't occur when compiled with -O2 -ftree-vectorize instead of -O3 (the
vectorizer generates the same code in both cases).
--
irar at il dot ibm dot com ch
--- Comment #5 from irar at il dot ibm dot com 2008-06-17 11:49 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|NEW
--- Comment #3 from irar at il dot ibm dot com 2008-06-26 06:24 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from irar at il dot ibm dot com 2008-06-26 11:57 ---
For access function (short int) {(short unsigned int) i_44, +, 1}_1)
evolution_part_in_loop_num() returns NULL, which causes the failure.
I tried to peel NOP_EXPRs from POLYNOMIAL_CHRECs in
evolution_part_in_loop_num
--- Comment #4 from irar at il dot ibm dot com 2008-06-26 18:33 ---
(In reply to comment #3)
> Can't you simply handle a NULL return
> from evolution_part_in_loop_num in the vectorizer?
The problem is that this happens during the transformation (for the code
created by the
--- Comment #5 from irar at il dot ibm dot com 2008-06-29 12:25 ---
It's a bug in calculation of number of iterations of prolog loop. I am testing
the following patch:
Index: tree-vect-transform.c
===
--- tree
--- Comment #8 from irar at il dot ibm dot com 2008-07-01 06:12 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #14 from irar at il dot ibm dot com 2008-07-06 11:54 ---
All those failures occur because vector multiplication of shorts to shorts is
not supported on power. Paolo's patch changed the order of type conversion and
multiplication, and removed type conversions.
All
--- Comment #15 from irar at il dot ibm dot com 2008-07-06 11:55 ---
(In reply to comment #14)
> Also Victor tried to reproduced the behavior that Kenny described in
> comment #3
comment #1
Sorry,
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35642
--- Comment #16 from irar at il dot ibm dot com 2008-07-06 11:57 ---
(In reply to comment #15)
> (In reply to comment #14)
> > Also Victor tried to reproduced the behavior that Kenny described in
> > comment #3
>
> comment #1
Grrr, it was in the problem d
--
irar at il dot ibm dot com changed:
What|Removed |Added
Priority|P1 |P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35642
--- Comment #5 from irar at il dot ibm dot com 2008-07-16 06:19 ---
This seems to fix the problem:
Index: tree-chrec.c
===
--- tree-chrec.c(revision 137271)
+++ tree-chrec.c(working copy)
@@ -696,6 +696,8
--- Comment #2 from irar at il dot ibm dot com 2006-01-29 10:10 ---
Changing double to float, the scalar evolution analyzer returns access function
(float *) ((unsigned int) {0, +, 1}_1 * 4) + (float *) a_12,
since it fails in type conversion:
(failed conversion:
type: unsigned int
--- Additional Comments From irar at il dot ibm dot com 2005-04-25 09:58
---
The vectorizer fails to determine dependence between: (*a_38)[D.719_49] and
(*a_38)[D.718_51], since it fails to determine that both of the data-refs have
the same base, *a_38. This is already fixed in
--- Additional Comments From irar at il dot ibm dot com 2005-04-26 10:04
---
We get the following code for the loop:
this_5 = &b_4->D.2068;
D.2080_9 = this_5->d[i_18];
b_4->D.2068.d[i_18] = D.2080_9;
In analysis of data-ref this_5->d[i_18] we don't c
--- Additional Comments From irar at il dot ibm dot com 2005-05-22 11:42
---
The problem is in vect-none.c itself. This patch fixes the problem
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02124.html (waiting for ok).
--
What|Removed |Added
--- Additional Comments From irar at il dot ibm dot com 2005-05-23 05:28
---
My patch removes vect-none.c, so it's impossible to get failures on this
testcase. I guess, there is a problem either in how I created the patch (I
did 'cvs remove' and 'cvs add', and
--- Additional Comments From irar at il dot ibm dot com 2005-05-24 07:01
---
Thanks for fixing the patch.
I can't reproduce vect-106.c failure on i686-pc-linux-gnu. Could you please
give me some information?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21630
--- Additional Comments From irar at il dot ibm dot com 2005-05-24 11:57
---
I committed the patch, since I am not able to reproduce vect-106.c failure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21630
Priority: P2
Component: tree-optimization
AssignedTo: irar at il dot ibm dot com
ReportedBy: irar at il dot ibm dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc-apple-darwin7.0.0
GCC host triplet: powerpc-apple-darwin7.0.0
GCC target tripl
k n !=
2147483647.
--
Summary: Missed optimization
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
Rep
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: irar at il dot ibm dot com
ReportedBy: irar at il dot ibm dot com
CC: dorit at il dot ibm dot com,gcc-bugs at gcc dot gnu dot
org
GCC build triplet
--- Additional Comments From irar at il dot ibm dot com 2004-11-22 10:01
---
Created an attachment (id=7580)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7580&action=view)
Testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18607
--- Additional Comments From irar at il dot ibm dot com 2004-11-23 07:36
---
Fixed in http://gcc.gnu.org/ml/gcc-patches/2004-11/msg01747.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18607
--- Comment #3 from irar at il dot ibm dot com 2006-10-30 11:33 ---
I am getting another failure:
/home/irar/main-boot/build7/./gcc/xgcc -B/home/irar/main-boot/build7/./gcc/
-B/home/irar/main-boot/ppc64-redhat-linux/bin/
-B/home/irar/main-boot/ppc64-redhat-linux/lib/ -isystem
/home
--- Comment #4 from irar at il dot ibm dot com 2006-11-02 11:18 ---
The loop at config/rs6000/rs6000.c:3674 requires versioning for alignment, so
when bootstrapping with
"-ftree-vectorize -fno-tree-vect-loop-version" it does not get vectorized.
However, we still fail bootstr
--- Comment #5 from irar at il dot ibm dot com 2006-11-02 11:44 ---
I found that revision 110671 passed bootstrap with vectorization enabled, and
revision 110846 failed bootstrap with vectorization enabled (but passed w/o).
Janis - could you help track down the patch that exposed
--- Comment #7 from irar at il dot ibm dot com 2006-11-06 09:38 ---
Janis - thanks a lot for your help!
> http://gcc.gnu.org/viewcvs?view=rev&rev=110705
> r110705 | law | 2006-02-07 18:31:27 + (Tue, 07 Feb 2006)
In r110704 bootstrap passes with and w/o vectorization en
--- Comment #9 from irar at il dot ibm dot com 2006-11-07 08:31 ---
In r110758 (and r110705) bootstrap with BOOT_CFLAGS="-O2 -g -ftree-vectorize
-maltivec" fails with another error:
/Develop/main-110758/build-vect/./prev-gcc/xgcc
-B/Develop/main-110758/build-vect/./prev-gcc/
--- Comment #10 from irar at il dot ibm dot com 2006-11-07 08:32 ---
Created an attachment (id=12560)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12560&action=view)
recog.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
--- Comment #12 from irar at il dot ibm dot com 2006-11-08 08:40 ---
Jeff,
Thanks a lot! I will do the things you've suggested shortly. Meanwhile, out of
curiosity, I am attaching a "good" recog.i (built with vectorization enabled,
but the offending loop was not vectoriz
--- Comment #13 from irar at il dot ibm dot com 2006-11-08 08:41 ---
Created an attachment (id=12568)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12568&action=view)
"good" recog.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
--- Comment #14 from irar at il dot ibm dot com 2006-11-08 11:33 ---
(In reply to comment #11)
> 1. Put a breakpoint in tree_ssa_cd_dce when compiling the
> offending function from recog.c.When that breakpoint
> triggers issue:
> verify_ssa (true)
>
--- Comment #15 from irar at il dot ibm dot com 2006-11-08 12:05 ---
Additional behavior:
If I run bootstrap with BOOT_CFLAGS="-O2 -g -ftree-vectorize -maltivec"
(without -fdump-tree-vect-details), bootstrap fails with
../../gcc/gcc/recog.c: In function constrain_operands:
--- Comment #17 from irar at il dot ibm dot com 2006-11-09 10:15 ---
I applied the patch http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01043.html (a
fix for PR26197). The bootstrap with vectorization passes!
However, the failure in comment #3 still occurs in the later revisions. So, I
--- Comment #19 from irar at il dot ibm dot com 2006-11-12 09:52 ---
Janis,
Thanks a lot!
The range of the revisions is 110758 - 111615 (110758 passes bootstrap with
vectorization with the patch, 111615 fails with the error in comment #3).
I had to modify the patch and split it into
--- Comment #20 from irar at il dot ibm dot com 2006-11-12 09:55 ---
Created an attachment (id=12597)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12597&action=view)
The first part of the patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
--- Comment #21 from irar at il dot ibm dot com 2006-11-12 09:56 ---
Created an attachment (id=12598)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12598&action=view)
The second part of the patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
--- Comment #27 from irar at il dot ibm dot com 2006-11-22 11:15 ---
I committed the patch that enables vectorization of strided accesses
(http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01679.html), and now bootstrap
with vectorization fails also on x86 with the same error as in comment
--- Comment #5 from irar at il dot ibm dot com 2006-11-27 11:19 ---
The patch I committed (comment #4) fixes almost all the type mismatch
occurrences in the vectorizer, but there's one occurrence that still remains -
one of the vectorizer testcases (vect-reduc-dot-u8b.c) still
--- Comment #29 from irar at il dot ibm dot com 2006-12-04 09:24 ---
I reproduced the wrong printings on x86. It seems to be a problem in strided
access vectorization after all - no stores are generated. I am looking into
this.
Thanks,
Ira
--
http://gcc.gnu.org/bugzilla
--- Comment #30 from irar at il dot ibm dot com 2006-12-07 12:14 ---
I am testing a patch for x86 boostrap failure. It was caused by a bug in
vectorization of strided accesses analysis, and, therefore, has nothing to do
with the bootstrap failures on ppc.
Ira
--
http://gcc.gnu.org
--- Comment #31 from irar at il dot ibm dot com 2006-12-07 13:30 ---
(In reply to comment #17)
> I applied the patch http://gcc.gnu.org/ml/gcc-patches/2006-07/msg01043.html (a
> fix for PR26197). The bootstrap with vectorization passes!
> However, the failure in comment #3 sti
--- Comment #32 from irar at il dot ibm dot com 2006-12-11 12:46 ---
I am attaching the "bad" rs6000.s (generated with vectorization) and "good"
rs6000.s (generated with vectorization and -fno-move-loop-invariants) using
revision 110852 (from February 2006). I loo
--- Comment #33 from irar at il dot ibm dot com 2006-12-11 12:57 ---
Created an attachment (id=12779)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12779&action=view)
"Bad" rs6000.s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
--- Comment #34 from irar at il dot ibm dot com 2006-12-11 13:02 ---
Created an attachment (id=12781)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12781&action=view)
"Good" rs6000.s
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
gnu dot org
ReportedBy: irar at il dot ibm dot com
GCC build triplet: powerpc*-*
GCC host triplet: powerpc*-*
GCC target triplet: powerpc*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
--- Comment #7 from irar at il dot ibm dot com 2006-12-14 11:53 ---
So, it is an altivec bug and not vectorizer's. I opened a new PR 30210 instead.
I think, this PR can be closed.
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22372
--- Comment #35 from irar at il dot ibm dot com 2006-12-14 11:58 ---
Th problem was solved for i386 by
http://gcc.gnu.org/viewcvs?view=rev&revision=119779.
Ira
--
irar at il dot ibm dot com changed:
What|Removed |A
cc dot gnu dot org
ReportedBy: irar at il dot ibm dot com
GCC build triplet: ia64-*-*
GCC host triplet: ia64-*-*
GCC target triplet: ia64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30211
--- Comment #6 from irar at il dot ibm dot com 2006-12-14 12:41 ---
I couldn't reproduce the problem on x86. I ran it with valgrind
--leak-check=yes, is it correct?
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29925
--- Comment #5 from irar at il dot ibm dot com 2006-12-20 12:20 ---
Paolo, thanks for the explanation! The problem originates from PR 22372, so I
will not open another bug report for it.
Thanks,
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30210
--- Comment #8 from irar at il dot ibm dot com 2006-12-20 12:22 ---
As explained by Paolo in PR 30210, it is not an Altivec problem after all.
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22372
--- Comment #5 from irar at il dot ibm dot com 2007-01-07 07:40 ---
On the todo list.
BTW, vectorization of strided accesses was committed to the mainline 4.3.
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18438
--- Comment #8 from irar at il dot ibm dot com 2007-01-15 10:04 ---
(In reply to comment #2)
> I think this whole type issue is a mess and needs some improvement.
> Maybe next week I can get to that.
Andrew, are you still planning to solve this, or should I prepare a f
301 - 370 of 370 matches
Mail list logo
