--- Comment #2 from irar at il dot ibm dot com 2008-11-22 15:08 ---
(In reply to comment #1)
> This bug is shamefully incomplete. There is no way anyone willing to give
> this
> a look can know what to look for.
> For example, a few things one would have to know before he/
--- Comment #2 from irar at il dot ibm dot com 2008-12-11 08:02 ---
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
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--
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 2008-12-30 14:57 ---
(In reply to comment #6)
> t.i:3: note: Vectorization may not be profitable.
> why doesn't the cost model then disallow vectorization here?
This is misleading. It only means that there exists loop boun
--- 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<=nhttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=37194
--- 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
--- 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 "u
--- 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
--- 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 #6 from irar at il dot ibm dot com 2009-05-05 12:41 ---
Reproduced on x86_64-suse-linux.
Seems that, somehow, the vectorized version of loop in line 29 is performed,
even though the number of scalar iterations is 1.
--
irar at il dot ibm dot com changed
--- Comment #13 from irar at il dot ibm dot com 2009-05-10 09:20 ---
(In reply to comment #12)
> Well, that revision only enabled vectorization support for more things...
> (which is probably what makes this a regression in the first place).
Right, I think it is something
--- Comment #14 from irar at il dot ibm dot com 2009-05-10 11:00 ---
I am testing:
Index: tree-vect-data-refs.c
===
--- tree-vect-data-refs.c (revision 147329)
+++ tree-vect-data-refs.c (working copy
--- Comment #18 from irar at il dot ibm dot com 2009-05-11 12:45 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|ASSIGNED
ment of array elements is
greater than element size"
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
--- Comment #2 from irar at il dot ibm dot com 2009-05-25 08:20 ---
(In reply to comment #1)
> this is likely being fixed by Ira
I committed the fix. Could you please check if it really fixes this one as
well?
Thanks,
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40240
--- Comment #1 from irar at il dot ibm dot com 2009-05-26 08:58 ---
(In reply to comment #0)
> On Linux/ia64, revision 147829:
> http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00806.html
> caused:
> FAIL: Matrix4f -O3 compilation from source
Could you please provide some inf
--- Comment #4 from irar at il dot ibm dot com 2009-05-27 08:43 ---
The bug is in data-refs analysis for basic blocks: two accesses that are not
adjacent (reload.c:1370) are considered as adjacent, and, therefore, get
vectorized together, causing the wrong code generation.
--
irar
--- Comment #5 from irar at il dot ibm dot com 2009-05-27 09:59 ---
I'll test this patch tomorrow:
Index: tree-data-ref.c
===
--- tree-data-ref.c (revision 147903)
+++ tree-data-ref.c (working copy)
@@ -7
--- Comment #5 from irar at il dot ibm dot com 2009-05-30 16:53 ---
(In reply to comment #4)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > On Linux/ia64, revision 147829:
> > > http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00806.html
> > &
--
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 #8 from irar at il dot ibm dot com 2009-05-31 09:04 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #4 from irar at il dot ibm dot com 2009-05-31 10:55 ---
So, will "too many basic blocks in loop" be good enough? Because this is what
it is, the reason that the loop form is not suitable for the vectorizer is that
there are too many basic blocks in it.
--- Comment #6 from irar at il dot ibm dot com 2009-05-31 12:33 ---
For non-empty latch block we actually print "not vectorized: unexpected loop
form." So I can change it to "not vectorized: non-empty latch block", and
instead of "too many BBs" I c
--- Comment #9 from irar at il dot ibm dot com 2009-06-01 08:20 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|NEW
--- Comment #2 from irar at il dot ibm dot com 2009-06-07 07:59 ---
So, I guess this patch fixes it?
Thanks,
Ira
Index: tree-vect-patterns.c
===
--- tree-vect-patterns.c(revision 148035)
+++ tree-vect-patterns.c
--- Comment #12 from irar at il dot ibm dot com 2009-06-15 09:58 ---
(In reply to comment #9)
> The patch in comment #8 fixes the failures reported in comment #7. I now see
> (powerpc-apple-darwin9 with -m64):
> FAIL: gcc.dg/vect/vect-42.c scan-tree-dump-times vect "Align
--- Comment #17 from irar at il dot ibm dot com 2009-06-16 07:36 ---
Dominique,
Could you please try this patch (I changed (!a && !b) to !(a || b)).
Thanks,
Ira
Index: vect-42.c
===
--- vect-42.c (revisio
--- Comment #19 from irar at il dot ibm dot com 2009-06-16 10:18 ---
(In reply to comment #18)
> > Could you please try this patch (I changed (!a && !b) to !(a || b)).
> I am currently regtesting on my ppc and it takes a long time. Meanwhile I am
> not sure to unders
--- Comment #21 from irar at il dot ibm dot com 2009-06-16 11:08 ---
(In reply to comment #20)
> What are the expected patterns for the 3 variables
> with -m32 and -m64?
I am not sure, this is why I asked you if the target is
([istarget *-*-darwin*] && [is-effecti
--- Comment #23 from irar at il dot ibm dot com 2009-06-17 08:22 ---
(In reply to comment #22)
> My understanding is that ([istarget *-*-darwin*] && [is-effective-target
> lp64])
> should return false for -m32 and true for -m64. At least it is how it works on
>
--- Comment #25 from irar at il dot ibm dot com 2009-06-17 11:06 ---
(In reply to comment #24)
> If I add to vect-42.c (with my patch) the line
>
> /* { dg-final { scan-tree-dump-times "bla bla bla" 1 "vect" { target
vector_alignment_reachable } } } */
...
--- Comment #29 from irar at il dot ibm dot com 2009-06-17 12:40 ---
Oh, so the first dump you attached (in comment #11) was for -m32. Now it makes
sense.
I think, we have to distinguish between vect_no_align and the other cases. I
will prepare a patch tomorrow.
Thanks,
Ira
--- Comment #1 from irar at il dot ibm dot com 2009-06-17 12:46 ---
Could you please attach a vectorizer dump for one of them? I need to know what
prevented vectorization.
Thanks,
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40475
--- Comment #4 from irar at il dot ibm dot com 2009-06-18 07:17 ---
Created an attachment (id=18017)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18017&action=view)
patch to fix the tests
Thanks. It's misalignment.
Could you please check the attached patch?
--
ir
--- Comment #31 from irar at il dot ibm dot com 2009-06-18 08:03 ---
Created an attachment (id=18019)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18019&action=view)
patch to fix vect-42.c
I think the easiest way to fix it is to change the test to have one vetorizable
loo
--- Comment #33 from irar at il dot ibm dot com 2009-06-18 09:14 ---
Created an attachment (id=18020)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18020&action=view)
fix vect-42.c
OK, now I understand why we need two loops here (we need to pass the arrays as
parameters t
--- Comment #7 from irar at il dot ibm dot com 2009-06-21 07:32 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #2 from irar at il dot ibm dot com 2009-06-28 10:57 ---
So, the solution is to prevent vectorization of volatile types, like in the
patch below?
Index: tree-vect-data-refs.c
===
--- tree-vect-data-refs.c
--- Comment #7 from irar at il dot ibm dot com 2009-06-30 12:02 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|NEW
--- Comment #27 from irar at il dot ibm dot com 2009-07-05 06:48 ---
(In reply to comment #23)
> because there are two reductions in that loop which I think the vectorizer
> cannot handle:
Actually, the vectorizer can vectorize two reductions. I think, the problem is
in cond_e
--- Comment #2 from irar at il dot ibm dot com 2009-07-16 12:29 ---
pr40770.c:20: note: ==> examining statement: sincostmp.21_1 = __builtin_cexpi
(D.1625_3);
pr40770.c:20: note: get vectype for scalar type: complex double
pr40770.c:20: note: not vectorized: unsupported data-t
--- Comment #6 from irar at il dot ibm dot com 2009-07-16 17:31 ---
(In reply to comment #3)
> > make_vector_type returns NULL for this type.
> Yes - there is no vector type for complex double. But the vectorizer
> could query for a vector type for the complex component
--- Comment #3 from irar at il dot ibm dot com 2009-07-19 09:35 ---
Testing a fix.
Ira
--
irar at il dot ibm dot com changed:
What|Removed |Added
AssignedTo
--- Comment #7 from irar at il dot ibm dot com 2009-07-20 11:18 ---
AFAIU, querying for the component type of complex type is not difficult to
implement.
I think, that loop-based vectorization is preferable here, so we should stay
with vectorization factor of 2 for doubles.
The next
--- Comment #28 from irar at il dot ibm dot com 2009-07-20 12:03 ---
I've just committed a patch that adds support of cond_expr in reductions in
nested cycles (http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01124.html).
cond_expr cannot be vectorized in reduction of inner-most
--- Comment #5 from irar at il dot ibm dot com 2009-07-26 07:04 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #32 from irar at il dot ibm dot com 2009-07-26 07:48 ---
(In reply to comment #30)
> Regarding the just committed inline version: It would be interesting to know
> whether it is vectorizable (with/without -ffinite-math-only [i.e.
> -ffast-math]).
It depends on wh
--- Comment #34 from irar at il dot ibm dot com 2009-07-27 08:36 ---
(In reply to comment #33)
> Using the example from comment 23 with
...
> gfortran shows: test.f90:12: note: not vectorized: unsupported use in stmt.
> and needs 2.272s. (By comparison. 4.4 needs 3.688s.)
Th
--- Comment #38 from irar at il dot ibm dot com 2009-07-27 12:44 ---
I am not sure that that kind of computation can be generated automatically,
since in general the order of caclulation of cond_expr cannot be changed.
However, the loop can be split:
for (i = 0; i < end
--- Comment #41 from irar at il dot ibm dot com 2009-07-28 08:12 ---
That requires pattern recognition. MIN/MAX_EXPR are recognized by the first
phiopt pass, so MIN/MAXLOC should be either also recognized there or in the
vectorizer. (The phiopt pass transforms if clause to MIN/MAX_EXPR
--- Comment #10 from irar at il dot ibm dot com 2009-08-06 10:49 ---
Yes. The problem is that only a basic implementation was added. To vectorize
this code several improvements must be done: support stmt group sizes greater
than vector size, allow loads and stores to the same location
--- Comment #3 from irar at il dot ibm dot com 2009-08-09 12:15 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #6 from irar at il dot ibm dot com 2009-08-12 12:14 ---
Looks like a problem in data-ref analysis:
Creating dr for this_6(D)->_M_x[__k_87]
...
base_address: this_6(D)
offset from base address: 0
constant offset from base address: 0
step
--- Comment #8 from irar at il dot ibm dot com 2009-08-13 05:40 ---
(In reply to comment #7)
> Oh. Did you manage to reduce or reproduce with a smaller testcase?
No, I just looked at the vectorized loops. The guilty one is
bin/../lib/gcc/x86_64-unknown-linux-gnu/4.
--- Comment #10 from irar at il dot ibm dot com 2009-08-13 11:34 ---
Reduced testcase:
#include
#include
#define N 4
long int a[N];
int main ()
{
int k;
for (k = 0; k < N; ++k)
a[k] = a[k] != 5 ? 12 : 10;
for (k = 0; k < N; ++k)
printf ("%u ", a[k])
--- Comment #11 from irar at il dot ibm dot com 2009-08-13 11:36 ---
Created an attachment (id=18350)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18350&action=view)
The assembly for the long int version (wrong code)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41019
--- Comment #12 from irar at il dot ibm dot com 2009-08-13 11:37 ---
Created an attachment (id=18351)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18351&action=view)
The assembly for the int version (correct)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41019
--- 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=rev&rev=102356) is that my patch enables
data-refs analysis for INDIRECT_REFs. Similar ICE in PR 20256 happens also
before my p
--- 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 |
--- 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 aut
--- 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 |Ad
--- 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 vecto
--- 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
"
--- 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
RMED
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
--- 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
--- 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=rev&revisio
--- 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=13281&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31343
for (i=0; ihttp://gcc.gnu.org/bugzilla/show_bug.cgi?id=32806
--- Comment #1 from irar at il dot ibm dot com 2007-08-09 08:44 ---
I got this too on x86_64-linux.
I guess the guilty patch is
r127306 | chaoyingfu | 2007-08-09 01:29:12 +0300 (Thu, 09 Aug 2007) | 213 lines
since it added the function fixed_zerop:
* tree.c
-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://gcc.gnu.org/bugzilla/show_bug.cgi?id=33447
--- Comment #4 from irar at il dot ibm dot com 2007-09-17 08:59 ---
(In reply to comment #3)
> I can reproduce that on x86_64-linux with trunk rev. 128442.
Dorit's fix is revision 128514, so it is not supposed to work on 128442...
Anyway, I am trying to reproduce this ICE o
--- Comment #5 from irar at il dot ibm dot com 2007-09-17 09:54 ---
(In reply to comment #4)
> Anyway, I am trying to reproduce this ICE on x86_64-linux now, with the
> current
> trunk (128538).
It doesn't ICE for me. (The loop gets vectorized).
Ira
--
http
--- Comment #1 from irar at il dot ibm dot com 2007-09-30 09:42 ---
I managed to reproduce it.
Here http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01559.html Richard suggested
to add a GTY(()) to
struct spu_builtin_description spu_builtins[] = {
#define DEF_BUILTIN(fcode, icode, name
--- Comment #6 from irar at il dot ibm dot com 2007-09-30 10:37 ---
(In reply to comment #5)
> Patch in testing:
Thanks for fixing this!
(I've just started to test the exact same patch :))
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33597
--- Comment #3 from irar at il dot ibm dot com 2007-10-02 09:22 ---
(In reply to comment #2)
> This is kinda on my list of stuff to forward port from the internal PS3
> toolchain.
Maybe I can help with testing this patch for mainline?
Thanks,
Ira
--
http://gcc.gnu.org/bu
--- Comment #7 from irar at il dot ibm dot com 2007-10-07 12:31 ---
(In reply to comment #3)
I get:
pr33680.c: In function גfג:
pr33680.c:1: error: expected an SSA_NAME object
pr33680.c:1: error: in statement
D.1618_93 = D.1556 /[ex] 4;
pr33680.c:1: internal compiler error: verify_ssa
--- Comment #9 from irar at il dot ibm dot com 2007-10-09 12:49 ---
(In reply to comment #8)
> If you use force_gimple_operand_bsi, it takes care of that itself.
Thanks! I will try to see if we can use it. The problem is we don't have a bsi,
we insert those stm
--- Comment #11 from irar at il dot ibm dot com 2007-10-10 13:23 ---
I understand that those symbols have to be renamed, I am just saying that maybe
it should be done in the gimplifier and not in the vectorizer. But since
force_gimple_operand_bsi also goes through the statements list
--- Comment #13 from irar at il dot ibm dot com 2007-10-11 10:43 ---
Maybe we can fix DCE not to eliminate such vars?
Or somehow fix split_constant_offset?
The following patch changes the base from
(int[0:D.1553] *) newcentroid.1_22 + (long unsigned int) dim_4(D) * 8
to (int[0:D.1553
--- Comment #14 from irar at il dot ibm dot com 2007-10-11 12:34 ---
BTW, without this patch http://gcc.gnu.org/ml/gcc-patches/2007-07/msg02122.html
there is no ICE and the loop gets vectorized.
Ira
--
irar at il dot ibm dot com changed:
What|Removed
--- Comment #16 from irar at il dot ibm dot com 2007-10-15 10:42 ---
This patch fixes the ICE and doesn't cause regressions in the vectorizer
testsuite:
Index: tree-data-ref.c
===
--- tree-data-ref.c (revision 1
--- Comment #3 from irar at il dot ibm dot com 2007-10-18 08:33 ---
It works fine for me (and the loop gets SLPed) on powerpc-64 and x86_64.
Could you please run it with -fdump-tree-vect-details and attach the dump file?
Ira
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33804
ity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: irar at il dot ibm dot com
GCC build triplet: powerpc64-suse-linux
GCC host triplet: powerpc64-suse-linux
GCC target triplet: powerpc64-suse-linux
http://
--- Comment #5 from irar at il dot ibm dot com 2007-10-21 08:45 ---
(In reply to comment #4)
> Created an attachment (id=14370)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14370&action=view) [edit]
> Vectorization dump file
>
Thanks!
The vectorizer fails i
--- Comment #4 from irar at il dot ibm dot com 2007-10-21 11:02 ---
The problem is with vector shift with scalar shift argument.
For the code created by the vectorizer:
vect_var_.49_103 = ~vect_var_.47_101;
vect_var_.50_105 = vect_var_.49_103 >> 31;
(ashiftrt:V4SI (no
--- Comment #6 from irar at il dot ibm dot com 2007-10-21 12:52 ---
The solution can be just not check if the vectorization is worthwhile during
the transformation. The decision whether to vectorize or not should be made
during the analysis anyway.
The vectorization factor can get
--- 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
1 - 100 of 370 matches
Mail list logo
