--- 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
--
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
--
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 #4 from irar at il dot ibm dot com 2008-08-20 12:18 ---
I am testing the following patch:
Index: tree-vect-analyze.c
===
--- tree-vect-analyze.c (revision 139225)
+++ tree-vect-analyze.c (working copy
--- Comment #1 from irar at il dot ibm dot com 2008-08-23 11:31 ---
I think it's a duplicate of pr37174.
I've just committed the fix.
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37209
--- Comment #8 from irar at il dot ibm dot com 2008-08-23 11:32 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from irar at il dot ibm dot com 2008-09-03 10:43 ---
(In reply to comment #7)
> I still think that handling NULL from evolution_part_in_loop_num is the
> correct thing to do. Even if you need to move this check to the analysis
> phase.
>
> The interestin
--- Comment #19 from irar at il dot ibm dot com 2008-09-07 11:05 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|NEW
--- Comment #12 from irar at il dot ibm dot com 2008-09-07 11:05 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|NEW
Status: 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=37416
--- Comment #13 from irar at il dot ibm dot com 2008-09-08 07:44 ---
(In reply to comment #9)
> Subject: Re: [4.3/4.4 Regression] ICE in vect_update_ivs_after_vectorizer
>
> > Another thing, 4.4 does not vectorize this loop anymore (and, therefore,
> > there
>
--- Comment #6 from irar at il dot ibm dot com 2008-09-09 08:24 ---
(In reply to comment #5)
> This looks related to PR 37418.
The testcase in PR 37418 ICEs also with -fno-tree-vectorize.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37385
--- Comment #8 from irar at il dot ibm dot com 2008-09-10 07:48 ---
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 #4 from irar at il dot ibm dot com 2008-09-11 09:58 ---
Testing:
Index: tree-vect-analyze.c
===
--- tree-vect-analyze.c (revision 140274)
+++ tree-vect-analyze.c (working copy)
@@ -3200,6 +3200,10
--- Comment #1 from irar at il dot ibm dot com 2008-09-14 07:00 ---
I think those loops are not supposed to get vectorized. E.g., in
gcc.target/i386/vectorize2.c the store statement b[i_14] = D.1579_6 is not
vectorizable because vector long int (the vector type of the statement taken
--
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 #3 from irar at il dot ibm dot com 2008-09-14 10:04 ---
(In reply to comment #2)
> I don't follow. For vectorize2.c we have
>
> b[i] = lrint (a[i]);
>
> where we should be able to vectorize this using lrint vectorization and
> a scalar long ->
--- Comment #5 from irar at il dot ibm dot com 2008-09-14 12:05 ---
(In reply to comment #4)
> For the 32bit case the problem is really the choice of the vector
> type for the store (where is this decided on?). As the type of
> b is int it should have chosen vector int i
--- Comment #7 from irar at il dot ibm dot com 2008-09-15 09:11 ---
(In reply to comment #6)
>
> I see vect_create_data_ref_ptr is getting the type to use passed
> in case of stores and this is TREE_TYPE (vec_oprnd) - is vec_oprnd
> the lhs or the rhs? It looks like i
--- Comment #4 from irar at il dot ibm dot com 2008-09-18 07:26 ---
Reduced testcase:
typedef struct _OilFunctionImpl OilFunctionImpl;
struct _OilFunctionImpl {
void *func;
};
static void
ayuv2yuyv_ref (int *d, int *src, int n)
{
char *dest = (char *)d;
int i;
for(i=0;i>
--
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 #6 from irar at il dot ibm dot com 2008-09-21 07:54 ---
(In reply to comment #5)
> The data dependence on the previous loop is clearly not considered, the loop
> is
> vectorized as if c on the rhs and c on the lhs were different non-overlapping
> arrays.
--- Comment #14 from irar at il dot ibm dot com 2008-09-22 09:24 ---
This patch causes the following failures on ppc:
FAIL: gcc.dg/vect/pr35821-altivec.c scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/vect/slp-perm-1.c scan-tree-dump-times vect "vector
--- Comment #16 from irar at il dot ibm dot com 2008-09-22 10:33 ---
(In reply to comment #15)
> This is because the original access is through a restricted pointer, so the
> check is conservatively correct at this point. We can move it to the
> point where the vector p
--- Comment #19 from irar at il dot ibm dot com 2008-09-22 12:32 ---
(In reply to comment #18)
> Created an attachment (id=16377)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16377&action=view) [edit]
> patch
>
> Actually this one vectorizes slp-perm-1.c for
--- Comment #20 from irar at il dot ibm dot com 2008-09-22 12:41 ---
(In reply to comment #18)
> Created an attachment (id=16377)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16377&action=view) [edit]
> patch
>
> Actually this one vectorizes slp-perm-1.c for
--- Comment #5 from irar at il dot ibm dot com 2008-09-28 06:17 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from irar at il dot ibm dot com 2008-10-07 11:25 ---
This seems to be similar to the failure in PR 37385 (in set_mem_alias_set, at
emit-rtl.c:1789). There the ICE was because the lhs and the element type of rhs
did not alias.
--
irar at il dot ibm dot com changed
--- Comment #4 from irar at il dot ibm dot com 2008-11-06 08:50 ---
> Maybe the complete source will be better...
I don't see any failure with r141636 on x86_64-linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37955
--- Comment #2 from irar at il dot ibm dot com 2008-11-11 09:24 ---
I am testing the following:
Index: tree-vect-analyze.c
===
--- tree-vect-analyze.c (revision 141763)
+++ tree-vect-analyze.c (working copy)
@@ -3314,8
--- Comment #6 from irar at il dot ibm dot com 2008-02-07 10:53 ---
(In reply to comment #2)
> Yes the loop is vectorized.
...
> Eyal.cpp:34: note: created 9 versioning for alias checks.
> Eyal.cpp:34: note: LOOP VECTORIZED.(get_loop_exit_condition
The vectorizer create
--- Comment #9 from irar at il dot ibm dot com 2008-02-07 12:54 ---
(In reply to comment #8)
> {
> float *pTempSumPhase_Temp_cre_angle = (float*) malloc (sizeof(float)
> *m_nSamples);
> float *pTempSum2Phase_Temp_cre_angle = (float*) malloc (sizeof(float)
&
--- Comment #11 from irar at il dot ibm dot com 2008-02-07 13:04 ---
(In reply to comment #10)
> Is there some pragma or a coding convention I can use to make the compiler
> understant those pointers have nothing to do with each other?
There is __restrict__, but it is useful on
--- Comment #13 from irar at il dot ibm dot com 2008-02-07 13:22 ---
CC'ing Daniel and Diego, maybe they can help with the alias analysis issues.
--
irar at il dot ibm dot com changed:
What|Removed |
--- Comment #14 from irar at il dot ibm dot com 2008-02-07 20:44 ---
Giving it another thought, this is not necessary an alias analysis issue, even
that it fails to tell that the pointers not alias. Since in this case the
pointers do differ, the runtime test should take the flow to the
--- Comment #25 from irar at il dot ibm dot com 2008-02-11 13:35 ---
(In reply to comment #21)
> (In reply to comment #14)
> > Giving it another thought, this is not necessary an alias analysis issue,
> > even
> > that it fails to tell that the pointers not alia
tion
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=35224
Version: 4.3.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: irar at il dot ibm dot com
http
igned at gcc dot gnu dot org
ReportedBy: irar at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35229
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=35272
--- Comment #3 from irar at il dot ibm dot com 2008-03-04 13:30 ---
It fails in initialize_matrix_A() when called with chrec {0, +, {0, +, 4}_1}_2:
int_cst_value (CHREC_RIGHT (chrec)) ICEs, since CHREC_RIGHT (chrec) here is {0,
+, 4}_1.
Ira
--
irar at il dot ibm dot com changed
--- Comment #4 from irar at il dot ibm dot com 2008-03-04 15:44 ---
Isn't the same problem as in pr34635?
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35428
--- Comment #5 from irar at il dot ibm dot com 2008-03-13 06:51 ---
(In reply to comment #4)
> This still happens on mainline.
>
> I wonder if vectorizer infrastructure can be re-used here to detect unrolled
> and looped version of memset. In addition to loop that can be
--- Comment #4 from irar at il dot ibm dot com 2008-03-20 09:30 ---
I reproduced the failures with revision 133362 (and without
--disable-multilib). Reverting our patch (revision 133134) didn't help, I still
see the failures even without it.
Ira
--
irar at il dot ibm do
--- Comment #7 from irar at il dot ibm dot com 2008-04-07 07:06 ---
I am testing the following patch:
Index: tree-vect-transform.c
===
--- tree-vect-transform.c (revision 132478)
+++ tree-vect-transform.c
--- 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
..
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, but not to
--- 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 #8 from irar at il dot ibm dot com 2009-03-01 11:15 ---
(In reply to comment #7)
> > question is it OK to vectorize function that are in EH table?
> Well, we should transfer the EH region information to the vectorized
> statement in this case. Which might be t
--- 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 IC
--- 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-11 09:34 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|ASSIGNED
--- 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
--- 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 m
--- 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 #6 from irar at il dot ibm dot com 2009-04-01 11:21 ---
(In reply to comment #4)
> On i686-apple-darwin9, I need -m64 to get an ICE with the test in comment #3.
And if you change the types?
- double precision a(4,*),b(3,64),c(3,200),d(64)
+ dimension a(4,*
--- 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)
dim
--- 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 s
--
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 #1 from irar at il dot ibm dot com 2009-04-08 11:17 ---
A testcase for 4.5:
#define N 128
int out[N*4], out2[N], in[N*4];
void
foo ()
{
int i, a0, a1, a2, a3;
for (i = 0; i < N; i++)
{
a0 = in[i*4];
a1 = in[i*4 + 1];
a2 = in[i*4 + 2];
--- Comment #2 from irar at il dot ibm dot com 2009-04-16 10:26 ---
This patch fixes the type in pr34591.c (the vector type should be the type of
the reduction variable because we are looking for its initial value, and not
the type of the reduction statement, i.e., its RHS type):
Index
--- Comment #4 from irar at il dot ibm dot com 2009-04-20 11:30 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|ASSIGNED
nd doesn't do anything
else, there is no segfault.
--
Summary: Aligned access to unaligned address
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at
nd doesn't do anything
else, there is no segfault.
--
Summary: Aligned access to unaligned address
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at
nd doesn't do anything
else, there is no segfault.
--
Summary: Aligned access to unaligned address
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at
--- Comment #2 from irar at il dot ibm dot com 2009-04-27 05:55 ---
*** Bug 39926 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39907
--- Comment #1 from irar at il dot ibm dot com 2009-04-27 05:55 ---
Sorry.
*** This bug has been marked as a duplicate of 39907 ***
--
irar at il dot ibm dot com changed:
What|Removed |Added
--- Comment #9 from irar at il dot ibm dot com 2009-09-08 05:51 ---
Looks related to PR 39907.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41288
--- Comment #4 from irar at il dot ibm dot com 2009-09-27 08:06 ---
(In reply to comment #1)
> The interesting thing is that data-ref analysis sees 128bit alignment but
> the vectorizer still produces
> vect_var_.24_59 = M*vect_p.20_57{misalignment: 0};
> D.2564_12
--- Comment #6 from irar at il dot ibm dot com 2009-09-27 09:56 ---
(In reply to comment #5)
> >
> > "aligned to" refers to the offset misalignment and not to the misalignment
> > of
> > base.
> Hmm, I believe it refers to base + offse
--- Comment #3 from irar at il dot ibm dot com 2009-11-10 10:02 ---
(In reply to comment #0)
> This causes mgrid score to drop
> by almost 40% on x86_64 and the vectorized code is pretty bad because it
> uses unaligned accesses.
Is the vectorized code worse than the scalar
--- Comment #5 from irar at il dot ibm dot com 2009-11-12 07:51 ---
(In reply to comment #4)
> I didn't check yet. We'll work on a simple cost-model integration of
> predcom.
You mean, vectorizer cost model will take predcom into account?
If the vectorization is no
--- 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 #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
--- 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:
--- 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-
--- 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 a
--- 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
--- Comment #9 from irar at il dot ibm dot com 2007-07-03 16:43 ---
(In reply to comment #8)
> I can submit a patch for merging that part of code in trunk if you need
> this flag to test if you are in one or the other case.
I guess we can't vectorize the loop in this PR
--- Comment #12 from irar at il dot ibm dot com 2007-07-04 08:34 ---
(In reply to comment #10)
> I have committed the attached patch to trunk.
> Sebastian
Thanks a lot!
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32377
--- Comment #13 from irar at il dot ibm dot com 2007-07-08 10:00 ---
Hi Sebastian,
I was going to submit the attached patch, but now the analysis fails with
"affine-affine test failed: missing iteration counts" and distance vector is
not built (so the loop in this PR
--- Comment #14 from irar at il dot ibm dot com 2007-07-08 10:01 ---
Created an attachment (id=13869)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13869&action=view)
patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32377
--- Comment #2 from irar at il dot ibm dot com 2007-07-09 06:22 ---
I guess it's an if-cvt problem - nothing gets vectorized (and I also disabled
the vectorizer to be sure), and if-cvt is applied on function aa_renderpalette
(where it ICEs later).
Ira
--
irar at il dot ibm do
--- Comment #5 from irar at il dot ibm dot com 2007-07-11 10:49 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #2 from irar at il dot ibm dot com 2007-07-11 14:50 ---
I don't get any dependence test failures on current mainline. I think they were
solved by Zdenek's rewrite of data-refs' analysis, since I can still see those
failures on autovect-branch (with old data
--- 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
--
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 #17 from irar at il dot ibm dot com 2010-02-22 09:01 ---
Is there a way to pass alignment information similar to PR 39954?
Otherwise, a proper fix would be some inter-procedural analysis... Meantime, we
can do intra-procedural analysis and fail when we reach function
--- Comment #2 from irar at il dot ibm dot com 2010-03-28 08:59 ---
I think PR 35229 covers this issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43425
--- Comment #1 from irar at il dot ibm dot com 2010-03-28 09:41 ---
(In reply to comment #0)
> What does this message mean?
> "vector iteration cost = 2056 is divisible by scalar iteration cost = 4 by a
> factor greater than or equal to the vectorization factor =
--- Comment #2 from irar at il dot ibm dot com 2010-03-28 10:58 ---
(In reply to comment #0)
> sub_hfyu_median_prediction.c:18: note: not vectorized: unhandled data-ref
>
> Looking with GDB at it, I get:
> (gdb) p debug_data_references (datarefs)
> (Data Ref:
>
--- Comment #3 from irar at il dot ibm dot com 2010-03-28 11:07 ---
(In reply to comment #1)
> hadamard8_diff.c:44: note: not vectorized: unhandled data-ref
There is a function call in this loop as well.
> hadamard8_diff.c:26: note: not vectorized: data ref analysis failed D.2
101 - 200 of 370 matches
Mail list logo
