--- Comment #1 from irar at il dot ibm dot com 2010-03-28 11:16 ---
Looks similar to PR 32806.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43543
--- Comment #6 from irar at il dot ibm dot com 2010-03-28 18:05 ---
(In reply to comment #4)
> What about fixing the diagnostic message like this:
>
It would be nice to do the same for SLP (compute_data_dependences_for_bb) for
completeness.
Thanks,
Ira
> diff --git a/gcc/
--- Comment #7 from irar at il dot ibm dot com 2010-03-28 18:22 ---
(In reply to comment #5)
> When defining the missing function like this:
>
> static inline int mid_pred(int a, int b, int c)
> {
> int t= (a-b)&((a-b)>>31);
> a-=t;
> b
--- Comment #1 from irar at il dot ibm dot com 2010-04-08 17:14 ---
It probably happens because the vectorization is not profitable. Try
-fno-vect-cost-model flag.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43692
--- Comment #3 from irar at il dot ibm dot com 2010-04-08 17:33 ---
Both loops get vectorized for me with -O3 on x86_64-suse-linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43692
--- Comment #5 from irar at il dot ibm dot com 2010-04-08 17:59 ---
In GCC 4.4 the smaller loop gets completely unrolled before the vectorizer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43692
--
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 #7 from irar at il dot ibm dot com 2010-04-19 07:48 ---
Fixed on 4.6, 4.5 and 4.4.
--
irar at il dot ibm dot com changed:
What|Removed |Added
--- Comment #5 from irar at il dot ibm dot com 2010-04-19 14:35 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|NEW
--- Comment #8 from irar at il dot ibm dot com 2010-04-21 11:33 ---
Yes, it's possible to add this to SLP. But I don't understand how
D.3154_3 = COMPLEX_EXPR ;
should be vectorized. D.3154_3 is complex and the rhs will be a vector
{D.3163_8, D.3164_9} (btw, we have to chang
--- Comment #10 from irar at il dot ibm dot com 2010-04-21 18:33 ---
Thanks. So, it is not always profitable and requires a cost model.
I am now working on cost model for basic block vectorization, I can look at
this once we have one.
--
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
--- Comment #6 from irar at il dot ibm dot com 2010-04-22 18:11 ---
Yes, sorry about that. I updated the ChangeLogs.
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43482
--- Comment #1 from irar at il dot ibm dot com 2010-04-27 05:53 ---
Could you please give some more information? It doesn't fail on x86_64-linux.
(For SLP dump please use -fdump-tree-slp-details).
Thanks,
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43901
--- 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=9469&action=view)
Patch
Yes, you are right, I should check the type of the data-ref (array type in the
first cas
--- Comment #18 from irar at il dot ibm dot com 2009-11-23 09:02 ---
I tried to vectorize eval.f90 with 4.3 and mainline on x86_64-suse-linux. In
both cases no loop gets vectorized in subroutine eval. The k loop is not
vectorizable because the step of x is unknown (function argument
--
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 #20 from irar at il dot ibm dot com 2009-11-30 08:52 ---
Actually, PAREN_EXPRs are vectorizable (the support was added by you, Richard,
in your original PAREN_EXPR patch
http://gcc.gnu.org/viewcvs?limit_changes=0&view=revision&revision=132515 )).
The problem here
--- Comment #21 from irar at il dot ibm dot com 2009-11-30 08:54 ---
Created an attachment (id=19183)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19183&action=view)
Multiple types support patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
--- Comment #23 from irar at il dot ibm dot com 2009-11-30 12:20 ---
Applied:
http://gcc.gnu.org/viewcvs?limit_changes=0&view=revision&revision=154794
Thanks,
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42108
--- Comment #3 from irar at il dot ibm dot com 2009-12-06 13:25 ---
On powerpc64-suse-linux with current trunk calculix failed after a couple of
minutes with
-O3 -maltivec -ffast-math
-O3 -maltivec -ffast-math -fno-tree-vectorize
-O2 -maltivec -ffast-math
-O1 -maltivec -ffast-math
--- Comment #7 from irar at il dot ibm dot com 2009-12-15 08:25 ---
I can't reproduce it with current mainline on powerpc64-suse-linux. Could you
please attach vectorizer dump? Does the good old version gets vectorized? If
so, could you please attach it as well?
Thanks
--- Comment #11 from irar at il dot ibm dot com 2009-12-15 10:59 ---
Looks that it has to be my patch that enables vectorization of conditions:
r149806 | irar | 2009-07-20 14:59:10 +0300 (Mon, 20 Jul 2009) | 19 lines
* tree-vectorizer.h (vectorizable_condition): Add
--- Comment #13 from irar at il dot ibm dot com 2009-12-15 13:07 ---
(In reply to comment #12)
> > Looks that it has to be my patch that enables vectorization of conditions:
> I am doing a clean bootstrap of C and FORTRAN of revision 149805 to see if the
> test works for i
--- Comment #14 from irar at il dot ibm dot com 2009-12-15 13:08 ---
Created an attachment (id=19311)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19311&action=view)
powerpc64-suse-linux vect dump
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
--- Comment #16 from irar at il dot ibm dot com 2009-12-15 13:35 ---
But in comment #5 you wrote that it passes with the print, right? So, this dump
contains correct or incorrect code?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
--- Comment #21 from irar at il dot ibm dot com 2009-12-16 12:01 ---
Thanks.
I'll be able to look at this only on Sunday due to holidays.
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
--- Comment #23 from irar at il dot ibm dot com 2009-12-20 12:18 ---
The code that now gets vectorized is the summation of array 'reduce':
sum(reduce). It looks like the problem is with adding the reduction result to
the correct index of 'temp' (scalar code), and no
--- Comment #26 from irar at il dot ibm dot com 2009-12-20 13:46 ---
I think the problem is in alignment. We force alignment of temp.6 and temp.20 -
the arrays of relevant comaprison results - even though we don't vectorize
their loop. The decision whether we can force alignment is
--- Comment #28 from irar at il dot ibm dot com 2009-12-20 13:59 ---
Hm, I don't know, but this is my best guess - we change something in the code
that goes wrong...
We also force alignment of reduce, but the reduction computation looks ok.
--
http://gcc.gnu.org/bug
--- Comment #30 from irar at il dot ibm dot com 2009-12-22 11:42 ---
We can try to verify the alignment issue by applying the two hacks I am
attaching.
The first one disables alignment forcing for all the data-refs (and marks the
alignment as unknown). The loops are still vectorizable
--- Comment #31 from irar at il dot ibm dot com 2009-12-22 11:43 ---
Created an attachment (id=19370)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19370&action=view)
disable alignment forcing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
--- Comment #32 from irar at il dot ibm dot com 2009-12-22 11:44 ---
Created an attachment (id=19371)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19371&action=view)
force alignment of vectorized arrays only
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
--- Comment #36 from irar at il dot ibm dot com 2009-12-23 07:54 ---
Thanks!
So, it is alignment of the vectorized arrays. I'd like to do two more checks:
1. Just force alignment of the two arrays (temp and reduce) and do not
vectorize.
2. Force alignment of reduce only (and vect
--- Comment #37 from irar at il dot ibm dot com 2009-12-23 07:54 ---
Created an attachment (id=19377)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19377&action=view)
Force alignment but don't vectorize
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
--- Comment #38 from irar at il dot ibm dot com 2009-12-23 07:55 ---
Created an attachment (id=19378)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19378&action=view)
Force alignment of reduce only
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41082
--- Comment #40 from irar at il dot ibm dot com 2009-12-23 14:49 ---
(In reply to comment #39)
> I have regtested the patch in comment #31 and I have ~75 regressions on
> x86_64-apple-darwin10 in the gcc vect test suite (~100 on
> powerpc-apple-darwin9). Is this expected? a
--- Comment #7 from irar at il dot ibm dot com 2009-12-30 10:16 ---
The bug is in SLP load permutation analysis. I am testing a patch.
--
irar at il dot ibm dot com changed:
What|Removed |Added
--- Comment #42 from irar at il dot ibm dot com 2010-01-05 09:09 ---
So, it's enough to force alignment of reduce only (and to vectorize its loop)
to get wrong code. On the other hand, the result of the vectorized loop is
correct, and the problem is in choosing the correct index of
--- Comment #5 from irar at il dot ibm dot com 2010-01-10 08:22 ---
In vector_alignment_reachable_p() we check if an access is packed using
contains_packed_reference(). For packed accesses we return false, meaning
alignment is unreachable and peeling cannot be used.
In the attached
--- Comment #43 from irar at il dot ibm dot com 2010-01-10 13:43 ---
Since -O2 -ftree-vectorize doesn't cause bad code, it has to be some other
optimization on top of vectorized code that causes the problem.
Bad code is generated when the alignment of 'reduce' is
--- Comment #8 from irar at il dot ibm dot com 2010-01-12 08:08 ---
So, to be on the safe side, we should assume that COMPONENT_REFs are not
naturally aligned and never use peeling for them?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42652
--- Comment #10 from irar at il dot ibm dot com 2010-01-13 09:35 ---
Yes, I understand that we can't assume that an access is aligned if we can't
prove it's aligned. I don't understand how we can prove that a COMPONENT_REF is
aligned, i.e., if there is a way to
--
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 #13 from irar at il dot ibm dot com 2010-01-18 12:17 ---
Does something like this make sense? (With this patch we will never use peeling
for function parameters, unless the builtin returns OK to peel for packed
types).
Index: tree-vect-data-refs.c
--- Comment #3 from irar at il dot ibm dot com 2010-01-24 07:39 ---
This has already been discussed in PR 41464.
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42846
--- Comment #4 from irar at il dot ibm dot com 2010-07-27 09:25 ---
I am testing a patch.
--
irar at il dot ibm dot com changed:
What|Removed |Added
AssignedTo
--- Comment #4 from irar at il dot ibm dot com 2010-08-10 09:06 ---
I am testing the same patch as in comment #1.
Testcase that shows the problem:
int
foo(short x)
{
short i, y;
int sum;
for (i = 0; i < x; i++)
y = x * i;
for (i = x; i > 0; i--)
sum += y;
--- Comment #5 from irar at il dot ibm dot com 2010-08-10 10:23 ---
(In reply to comment #1)
> This patch should be a valid fix, because the recognition of the dot_prod
> pattern is known to be fail at this point if the stmt is outside the loop.
> (I am not sure whether we s
--- Comment #7 from irar at il dot ibm dot com 2010-08-11 10:24 ---
(In reply to comment #6)
> I think that SLP doesn't handle reduction.
>
Not all kinds of reduction. We handle
#a1 = phi
#b1 = phi
...
a2 = a1 + x
b2 = b1 + y
Here we also have:
#a1 = phi
...
a2 = a1
--- Comment #3 from irar at il dot ibm dot com 2010-09-01 09:06 ---
r163260 only made this BB vectorizable.
I checked lookup_stmt_eh_lp for the last stmt of the BB and EDGE_EH flags
before and after vectorization (basic block SLP), and in both cases
lookup_stmt_eh_lp returns 0 and
--- Comment #6 from irar at il dot ibm dot com 2010-09-01 11:54 ---
(In reply to comment #5)
> I see before SLP:
>
> :
> MEM[(struct A *)this_1(D)].a = 0;
> MEM[(struct A *)this_1(D)].b = 0;
> MEM[(struct A *)this_1(D)].c = 0;
> [LP 2] MEM[(struct A *)t
--- Comment #9 from irar at il dot ibm dot com 2010-09-12 09:46 ---
OK, thanks. I am going to test this patch, it only checks data-refs and
function calls:
Index: tree-vect-data-refs.c
===
--- tree-vect-data-refs.c
--- Comment #3 from irar at il dot ibm dot com 2010-09-19 08:52 ---
gimple_bb (stmt) returns NULL for that statement (D.1575_33 = __builtin_pow
(D.1542_14, D.1574_32)).
We can avoid vectorization in such cases, but looks like it should be fixed to
return the actual basic block.
Ira
--- Comment #5 from irar at il dot ibm dot com 2010-09-19 10:08 ---
Right. This patch fixes it:
Index: tree-vect-stmts.c
===
--- tree-vect-stmts.c (revision 164332)
+++ tree-vect-stmts.c (working copy)
@@ -4478,6
--- Comment #7 from irar at il dot ibm dot com 2010-09-20 06:43 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|NEW
--- Comment #2 from irar at il dot ibm dot com 2010-09-20 12:17 ---
Looks like it is caused by revision 164367:
http://gcc.gnu.org/ml/gcc-cvs/2010-09/msg00661.html
--
irar at il dot ibm dot com changed:
What|Removed |Added
--- Comment #3 from irar at il dot ibm dot com 2010-09-20 13:08 ---
For vector(2) void * we get vec_perm_v2di_u builtin declaration, because the
mode of vector(2) void * is unsigned V2DI.
I wonder if this can happen for every builtin call, and we should convert back
to the original
--- Comment #4 from irar at il dot ibm dot com 2010-05-02 05:51 ---
I don't have access to ia64. I tried to change the types in the test to make
the basic blocks vectorizable on x86_64, but didn't get any error. So I still
need SLP dump in order to solve this.
Thanks,
Ira
--- Comment #9 from irar at il dot ibm dot com 2010-05-02 11:08 ---
Thanks, Uros! I reproduced the ICE using your instructions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43901
--- Comment #10 from irar at il dot ibm dot com 2010-05-02 12:12 ---
Looks like it's caused by:
r158157 | rguenth | 2010-04-09 13:40:14 +0300 (Fri, 09 Apr 2010) | 28 lines
The problem is in getting vectype for f1_2:
foo (int b, double f1, double f2, int c1, int c2)
{
...
fl
--- Comment #12 from irar at il dot ibm dot com 2010-05-03 12:30 ---
> Well. For loops we'd have disqualified it as there is no vector
> type for the external def (well, the stmt inside the loop).
I don't think that's true. With -fno-tree-pre we get
--- Comment #14 from irar at il dot ibm dot com 2010-05-05 09:02 ---
> It tries to get a _vector_ type of the same size. In theory each
> vectorization method can choose whatever vector size suits them
> most (as for external defs they need to build up a vector of e
--- Comment #16 from irar at il dot ibm dot com 2010-05-10 08:17 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from irar at il dot ibm dot com 2010-05-20 07:13 ---
Do you mean that extract_even implementation does something illegal with this
last element? Misaligned load also accesses elements outside the array, but the
problem is in extract_even?
Other than doing something in
--- Comment #3 from irar at il dot ibm dot com 2010-05-20 10:04 ---
I am curious what is the problem with that? These elements are not used, they
are just loaded...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44183
--- Comment #5 from irar at il dot ibm dot com 2010-05-20 10:24 ---
Even if we are talking about less than vector size from array boundary? And
that boundary is not (vector) aligned.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44183
--- Comment #5 from irar at il dot ibm dot com 2010-06-13 10:29 ---
The bug is in creation of a neutral value for BIT_AND_EXPR. What is the correct
way to create it for all types? I found
double-int.h:#define ALL_ONES (~((unsigned HOST_WIDE_INT) 0))
but it won't work for s
--- Comment #7 from irar at il dot ibm dot com 2010-06-13 12:01 ---
(In reply to comment #6)
> (In reply to comment #5)
> > The bug is in creation of a neutral value for BIT_AND_EXPR. What is the
> > correct
> > way to create it for all types? I found
> > do
riority: 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=44710
--- Comment #1 from irar at il dot ibm dot com 2010-06-29 09:11 ---
Created an attachment (id=21036)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21036&action=view)
Full testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44710
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=44711
--- Comment #1 from irar at il dot ibm dot com 2010-06-29 11:00 ---
Created an attachment (id=21037)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21037&action=view)
Full testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44711
--- Comment #1 from irar at il dot ibm dot com 2010-07-08 09:14 ---
The failure is in vectorizable_store():
/* If accesses through a pointer to vectype do not alias the original
memory reference we have a problem. This should never happen
--- Comment #7 from irar at il dot ibm dot com 2007-10-22 06:31 ---
Falk,
Could you please check if the patch in Comment #6 fixes the ICE?
Thanks,
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33804
--- Comment #4 from irar at il dot ibm dot com 2007-10-22 07:23 ---
I am testing the following patch:
Index: tree-vect-analyze.c
===
--- tree-vect-analyze.c (revision 129404)
+++ tree-vect-analyze.c (working copy
--- Comment #5 from irar at il dot ibm dot com 2007-10-22 11:52 ---
For the data ref in the testcase, VIEW_CONVERT_EXPR(0),
get_base_address() (in dr_analyze_alias) returns NULL, which causes the
segfault.
Ira
--
irar at il dot ibm dot com changed:
What|Removed
--- Comment #4 from irar at il dot ibm dot com 2007-10-24 07:48 ---
In this testcase we perform vectorization of strided accesses in a loop with
multiple types. In vectorizable_store() we gather all the scalar operands of
the stores in the strided accesses group and later call
--- Comment #8 from irar at il dot ibm dot com 2007-10-29 10:22 ---
I don't have access to ia64. Could you please attach vectorizer's dump
(-fdump-tree-vect-all)?
Thanks,
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33869
--- Comment #10 from irar at il dot ibm dot com 2007-10-30 10:09 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #6 from irar at il dot ibm dot com 2007-10-30 10:10 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|NEW
--- Comment #5 from irar at il dot ibm dot com 2007-10-31 10:57 ---
The problem here is that more than one vector stmts are used to vectorize (SLP)
this loop, while only one vector operand is created in case of vector shift
with scalar argument.
I am preparing a patch.
Thanks,
Ira
--- Comment #6 from irar at il dot ibm dot com 2007-10-31 11:22 ---
(In reply to comment #2)
> Uh, the VEC_* stuff used there looks like a mess. It's not clear who
> allocates
> and what the size should be.
I'll take a look and fix if necess
--- Comment #7 from irar at il dot ibm dot com 2007-10-31 12:57 ---
I am testing the following patch:
Index: tree-vect-transform.c
===
--- tree-vect-transform.c (revision 129627)
+++ tree-vect-transform.c
--- Comment #8 from irar at il dot ibm dot com 2007-11-06 13:17 ---
(In reply to comment #6)
> (In reply to comment #2)
> > For example vect_get_vec_defs_for_stmt_copy
> > doesn't allocate the VECs which is exactly what causes the problem here.
>
> vect_get
--- Comment #1 from irar at il dot ibm dot com 2007-11-29 09:31 ---
I can't reproduce this failure with the same flags with revision 130403 on
ppc64-redhat-linux.
(Some loops indeed get vectorized in reload.c and reload1.c:
reload1.c.104t.vect:reload1.c:2433: note: LOOP VECTO
--- Comment #32 from irar at il dot ibm dot com 2007-12-04 06:56 ---
(In reply to comment #30)
> Uh, sorry for being terse. If there are no loops, then "straight-line
> parallelization" [SLP] should vectorize your manually unrolled sequence in
> comment #24.
Curren
--- Comment #4 from irar at il dot ibm dot com 2007-12-04 07:31 ---
(In reply to comment #3)
> The failure occurs with "-m32 -O3 -maltivec -fno-strict-aliasing", but not
> without -fno-strict-aliasing.
Yes, I succeeded to reproduce the failure with -fno-strict-aliasi
--- Comment #5 from irar at il dot ibm dot com 2007-12-06 07:49 ---
It also fails with -O2 and -O1 (and not only with -O3).
The offending loop is reload.c:2352 (in function find_reloads):
for (i = 0; i < noperands; i++)
{
constraints[i] = constraints
--- Comment #6 from irar at il dot ibm dot com 2007-12-11 13:24 ---
The first difference I found between with and without -fno-strict-aliasing
versions of the loop in reload.c:2352 is in
with -fno-strict-aliasing (the "bad" one):
(insn 414 413 415 43 ../src/reload.c:2354
--- Comment #1 from irar at il dot ibm dot com 2008-01-01 10:02 ---
The failure occurs in is_gimple_val() for this variable. The problem is that
DECL_GIMPLE_REG_P for it is false. The vectorizer sets this value to be true
for every variable of the vector type that the vectorizer creates
--- Comment #10 from irar at il dot ibm dot com 2008-04-10 07:10 ---
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-04-22 07:57 ---
The problem here is that we do not check the types of interleaved data-refs,
but only their steps (and since float and int are of the same size here, their
steps are equal). And then we treat all the data-refs as if
--- Comment #7 from irar at il dot ibm dot com 2008-04-24 07:30 ---
(In reply to comment #6)
> Fixed on the 4.3 branch, but not on the trunk yet.
>
Yes, I'm going to do this during the next couple of hours.
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35982
ReportedBy: irar at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36033
--- Comment #9 from irar at il dot ibm dot com 2008-04-24 09:40 ---
Fixed.
I opened pr36033 to get rid off the redundant loads.
Ira
--
irar at il dot ibm dot com changed:
What|Removed |Added
201 - 300 of 370 matches
Mail list logo
