--- Comment #7 from irar at il dot ibm dot com 2006-09-13 08:32 ---
I think, the problem here is that we only check SMT and not NMT. I am preparing
a patch to fix this. NMT is stored in ptr_info_def of data-ref, and only if it
does not exist, SMT will be checked.
--
irar at il dot
--- Comment #3 from irar at il dot ibm dot com 2006-09-19 07:10 ---
t.c:20: note: not vectorized: mixed data-types
t.c:20: note: can't determine vectorization factor.
Removing flags[i] = true;
Multiple data-types vectorization is already supported in the autovect branch
--- Comment #7 from irar at il dot ibm dot com 2006-09-19 07:29 ---
Even though vectorization of strided accesses is already implemented in the
autovect branch (and will be committed to the mainline 4.3), this case contains
a store with a gap (store to a[i] without a store to a[i-1
--- Comment #15 from irar at il dot ibm dot com 2006-10-18 11:03 ---
(In reply to comment #13)
We need to check if above patch fixes PR26969 as well.
Checked, it does not.
--
irar at il dot ibm dot com changed:
What|Removed |Added
--- 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 bootstrap
--- 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=revrev=110705
r110705 | law | 2006-02-07 18:31:27 + (Tue, 07 Feb 2006)
In r110704 bootstrap passes with and w/o vectorization enabled
--- 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/
-B/Develop
--- 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=12560action=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 vectorized).
BTW, here
--- 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)
I can't see any
--- 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:
../../gcc
--- 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
--- 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=12597action=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=12598action=view)
The second part of the patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752
--- Additional Comments From irar at il dot ibm dot com 2005-02-24 13:41
---
I found the problem that causes this. I'll send the patch next week.
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20122
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com
|dot org |
Status|NEW
--- Additional Comments From irar at il dot ibm dot com 2005-03-02 12:45
---
Fixed in http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01788.html. Waiting for
review.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20122
--- Additional Comments From irar at il dot ibm dot com 2005-03-09 06:56
---
New testcase added: vect-3.f90 (in autovect branch for now).
If this PR is solved, testcase vect-3.f90 will be vectorized.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18527
--- Additional Comments From irar at il dot ibm dot com 2005-03-15 11:37
---
This problem was solved in autovect branch (http://gcc.gnu.org/ml/gcc-
patches/2005-03/msg00754.html). This patch will be submitted to mainline in
stage 2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- 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
--- 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 check that the initial
condition
--- 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 'cvs diff -N' afterwards
--- 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
--- Comment #4 from irar at il dot ibm dot com 2005-12-14 13:11 ---
I think the reason why this ICE occurs with my patch
(http://gcc.gnu.org/viewcvs?view=revrev=102356) is that my patch enables
data-refs analysis for INDIRECT_REFs. Similar ICE in PR 20256 happens also
before my patch
--- Comment #3 from irar at il dot ibm dot com 2005-12-18 08:15 ---
I failed to reproduce this ICE on ppc and i686.
Vectorizer's dump file can help.
--
irar at il dot ibm dot com changed:
What|Removed |Added
--- 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
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
.
--
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
ReportedBy: irar at il dot
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=7580action=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
--- Additional Comments From irar at il dot ibm dot com 2005-06-30 11:38
---
Submitted a patch that fixes this: http://gcc.gnu.org/ml/gcc-patches/2005-
06/msg02228.html
--
What|Removed |Added
--- Additional Comments From irar at il dot ibm dot com 2005-07-07 07:47
---
The problem occurs in decision whether the number of loop iterations is greater
than zero. The (single) predecessor edge is checked for being EDGE_TRUE_VALUE
or EDGE_FALSE_VALUE, and the corresponding
--- Additional Comments From irar at il dot ibm dot com 2005-07-21 05:45
---
I submitted a patch to fix this - http://gcc.gnu.org/ml/gcc-patches/2005-
07/msg01388.html
--
What|Removed |Added
--- Additional Comments From irar at il dot ibm dot com 2005-07-26 07:07
---
The data dependence issue was solved by this patch http://gcc.gnu.org/ml/gcc-
patches/2005-07/msg01195.html (committed). However, this loop is still not
vectorizable because of noncontinuous access
--- Additional Comments From irar at il dot ibm dot com 2005-08-11 08:14
---
Created an attachment (id=9469)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9469action=view)
Patch
Yes, you are right, I should check the type of the data-ref (array type in the
first case). And instead
--- Comment #3 from irar at il dot ibm dot com 2005-10-12 09:00 ---
I think, it's the same bug in scev that my autovect patch
http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00252.html solved (and Sebastian
reverted it).
Here scev analyzer calculates the evolution of 'D.1703_5 * 2 + i_15
--- 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 fails
--- 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 still occurs
--- 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 looked over these a bit, but I
--- 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=12779action=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=12781action=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=revrevision=119779.
Ira
--
irar at il dot ibm dot com changed:
What|Removed |Added
: 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 fix
--- Comment #3 from irar at il dot ibm dot com 2007-01-28 10:45 ---
The current versions of both mainline and autovect branch do not ICE. Strided
loads are not implemented for SSE. I opened a PR 30211 for it.
I think this PR can be closed.
Ira
--
irar at il dot ibm dot com changed
--- Comment #3 from irar at il dot ibm dot com 2007-01-28 11:38 ---
I tried to reproduce this on x86 with current autovect branch and mainline with
.../g++ -fpreprocessed tmp.ii -S -O3 -ftree-vectorize -msse2 -ansi
-fdump-tree-vect-details. It doesn't not ICE, and the loop is vectorized
--- Comment #5 from irar at il dot ibm dot com 2007-02-19 11:18 ---
Subject: Re: ice for legal code with -ftree-vectorize -O2
I know what the problem is. If we don't remove the store while iterating,
we can't get it later (the si), can we?
Ira
dorit at il dot
--- Comment #6 from irar at il dot ibm dot com 2007-02-19 12:41 ---
Sorry about the last comment, it was sent by mistake.
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30843
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: irar at il dot ibm dot com
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http
--- Comment #1 from irar at il dot ibm dot com 2007-02-22 07:58 ---
Here is the ChangeLog entry for that patch:
2007-02-09 Richard Henderson [EMAIL PROTECTED]
* config/i386/constraints.md (Ym): New constraint.
* config/i386/i386.md (movsi_1): Change Y2 to Yi
--- Comment #3 from irar at il dot ibm dot com 2007-02-22 08:22 ---
(In reply to comment #2)
(In reply to comment #0)
Bootstrap with vectorization enabled fails on i386 starting from revision
121767:
http://gcc.gnu.org/viewcvs?view=revrevision=121767
Could you post exact steps
--- Comment #15 from irar at il dot ibm dot com 2007-03-05 09:30 ---
I tried the reduced testcase on powerpc with -ftree-loop-linear and both -O2
and -O3 on 4.1, 4.2 and 4.3, and it works fine.
Ira
--
irar at il dot ibm dot com changed:
What|Removed
--- Comment #6 from irar at il dot ibm dot com 2007-03-11 10:33 ---
Harsha, could you please attach vectorizer's dump file (produced with
-fdump-tree-vect-details)?
Thanks,
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25371
: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: irar at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31343
--- Comment #1 from irar at il dot ibm dot com 2007-03-25 10:02 ---
Created an attachment (id=13281)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13281action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31343
--- Comment #1 from irar at il dot ibm dot com 2007-05-21 10:43 ---
On PowerPC revision 124785 from May 17 we get:
FAIL: gcc.dg/vect/vect-64.c (internal compiler error)
FAIL: gcc.dg/vect/vect-64.c (test for excess errors)
WARNING: gcc.dg/vect/vect-64.c compilation failed to produce
--- Comment #8 from irar at il dot ibm dot com 2009-01-05 13:58 ---
To handle unknown alignment of data, the vectorizer creates a prolog loop to
peel a statically unknown number of scalar iterations (0=nVF). This loop is
followed by a vectorized loop (with the remaining, multiple of VF
--- Comment #1 from irar at il dot ibm dot com 2009-01-05 13:19 ---
Here is a reduced testcase:
program test_elemental
implicit none
integer, dimension (2, 4) :: a
integer, dimension (2, 4) :: b
integer(kind = 8), dimension(2) :: c
a = reshape ((/2, 3, 4, 5, 6, 7, 8, 9
--- Comment #12 from irar at il dot ibm dot com 2009-01-08 09:25 ---
(In reply to comment #11)
fixed for 4.3.3?
Thanks.
No, still waiting for approval.
--
irar at il dot ibm dot com changed:
What|Removed |Added
--- Comment #4 from irar at il dot ibm dot com 2009-01-11 07:48 ---
Fixed on 4.3 branch as well.
--
irar at il dot ibm dot com changed:
What|Removed |Added
--- Comment #14 from irar at il dot ibm dot com 2009-01-11 07:57 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|REOPENED
--- Comment #6 from irar at il dot ibm dot com 2009-01-25 09:12 ---
(In reply to comment #5)
So,
4) The vectorized version sucks because we have to use peeling for niters
because we need to unroll the loop once and cannot apply SLP here.
What do you mean by unroll the loop once
--- Comment #8 from irar at il dot ibm dot com 2009-01-25 12:17 ---
(In reply to comment #7)
Q1: does SLP work with reductions at all?
No. SLP currently originates from groups of strided stores.
Ah, I see. In this loop we have two reductions, so to apply SLP
we would need
--- Comment #3 from irar at il dot ibm dot com 2009-01-26 13:09 ---
(In reply to comment #2)
Now, I wonder why we do not just use alignment + misalign in that case.
I think you are right.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38968
--- Comment #4 from irar at il dot ibm dot com 2009-02-25 07:06 ---
Does adding attribute aligned, as below, help?
Index: vect-complex-1.c
===
--- vect-complex-1.c(revision 144030)
+++ vect-complex-1.c(working copy
--- Comment #4 from irar at il dot ibm dot com 2009-02-25 14:08 ---
Looks similar to PR 35229.
We get here:
# pre.1 = PHI D.1, D.2
..
load D.2
D.3 = D.2 + pre.1 + ...
store D.3
--
irar at il dot ibm dot com changed:
What|Removed |Added
--- Comment #7 from irar at il dot ibm dot com 2009-02-26 09:57 ---
In slp-7.c all the three loops get vectorized, including the loop that requires
vector multiplication for shorts. This patch
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00044.html added ARM to
vect_int_mult
--- Comment #6 from irar at il dot ibm dot com 2009-03-01 10:34 ---
Reduced it a bit more:
subroutine adw_trajsp (F_u,i0,in,j0,jn)
implicit none
real F_u(*)
integer i0,in,j0,jn
integer n,i,j
real*8 xsin(i0:in,j0:jn)
!$omp parallel do private(xsin
--- Comment #10 from irar at il dot ibm dot com 2009-03-01 12:27 ---
(In reply to comment #9)
Ok. Then
if (maybe_clean_or_replace_eh_stmt (old_stmt, new_stmt))
gimple_purge_dead_eh_edges (bb);
should be enough to fix this.
Richard.
Yes, it fixes the ICE. Thanks! I'll submit
--- Comment #10 from irar at il dot ibm dot com 2009-03-08 07:25 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #1 from irar at il dot ibm dot com 2009-03-10 13:55 ---
I am preparing a patch.
--
irar at il dot ibm dot com changed:
What|Removed |Added
AssignedTo
--- Comment #3 from irar at il dot ibm dot com 2009-03-17 13:33 ---
(In reply to comment #2)
Or like the following, which is just a bunch of reductions of two elements
float data[1024];
void foo(void)
{
int i;
for (i = 1; i 1024; ++i)
data[i] = data[i] + data[i-1
--- Comment #2 from irar at il dot ibm dot com 2009-03-24 08:23 ---
I am testing this patch:
Index: tree-vect-transform.c
===
--- tree-vect-transform.c (revision 145027)
+++ tree-vect-transform.c (working copy
--- Comment #3 from irar at il dot ibm dot com 2009-03-24 11:42 ---
(In reply to comment #0)
My solution:
After each loop is vectorized, and SSA is updated, I re-compute alias
info. I am not familiar with the vectorizer sources, so I don't know
if there is a more efficient way
--- Comment #5 from irar at il dot ibm dot com 2009-03-25 12:27 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|NEW
--
irar at il dot ibm dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |irar at il dot ibm dot com
|dot org
--- Comment #9 from irar at il dot ibm dot com 2009-04-02 10:07 ---
Will the following test do the job? (I added -m64 for target i686-*-*)
! { dg-do compile }
! { dg-options -c -O3 -fdump-tree-vect-details -m64 { target i686-*-* } }
subroutine foo(a,c,i,m)
dimension a(4
--- Comment #11 from irar at il dot ibm dot com 2009-04-02 11:16 ---
(In reply to comment #10)
No, please don't ever add -m64 or -m32 to dg-options, that is something the
tester decides on in how it invokes make check. If a test is specific to -m64
or -m32, you should be using ilp32
--- Comment #5 from irar at il dot ibm dot com 2007-06-28 09:02 ---
I think it is better to check that the statement is not NULL before calling
bsi_insert_on_edge_immediate. I am going to prepare a patch for this.
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32230
--- Comment #6 from irar at il dot ibm dot com 2007-06-28 11:41 ---
((float*) (((sbuf_header_t *) ((buf) == (buf)-buf[0]))-buf[0]))[i] = val;
is (after ommiting the casts)
*(1B + (i * 4)) = val;
Is that legal?
Vectorizer assumes that every data-ref has base_address. In the above
--- Comment #8 from irar at il dot ibm dot com 2007-06-28 12:29 ---
(In reply to comment #7)
I suppose rejecting NULL bases should work here?
Yes, only it's not NULL it's zero (0B).
We can reject it in the vectorizer or not create a dr for it...
Ira
--
http://gcc.gnu.org
--- Comment #10 from irar at il dot ibm dot com 2007-06-28 12:38 ---
(In reply to comment #9)
I suppose all INTEGER_CST bases should be rejected.
Richard.
Right. The value actually doesn't matter since the constant part is split to
the init part in (tree-data-ref.c:656
--- Comment #3 from irar at il dot ibm dot com 2007-07-01 13:21 ---
A fix to PR 32230 http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00018.html fixes
this one too.
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32477
--- Comment #5 from irar at il dot ibm dot com 2007-07-02 12:20 ---
(In reply to comment #4)
Looks like the data-dependence analysis is doing it's job
I am not sure about that. I tried the following cases and got distance 1 (and
direction positive) in all of them for load and store
--- Comment #7 from irar at il dot ibm dot com 2007-07-03 12:57 ---
(In reply to comment #6)
Distance vectors are lexicographically positive vectors, that is why you get
the 1
in all these cases. If you want to know which one comes first, you have to
look
at the DR_IS_READ
1 - 100 of 361 matches
Mail list logo
