--- Comment #11 from dorit at il dot ibm dot com 2007-10-30 05:48 ---
(In reply to comment #6)
Richard, is this related to the issue you reported in
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01127.html
(looks like the same error)?
Any idea why the fix you committed doesn't cover
--- Comment #12 from dorit at il dot ibm dot com 2007-07-01 09:30 ---
Subject: Re: -ftree-vectorize results in internal compiler error on AMD64
Zdenek's patch for cleaning the dataref analysis is also fixing this bug.
http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00634.html
So now
--- Comment #19 from dorit at il dot ibm dot com 2007-06-29 16:46 ---
testing this patch for Altivec:
Index: config/rs6000/altivec.md
===
*** config/rs6000/altivec.md(revision 126053)
--- config/rs6000/altivec.md
--- Comment #5 from dorit at il dot ibm dot com 2007-06-27 11:57 ---
(In reply to comment #4)
(In reply to comment #3)
The problem is in -ftree-vectorize
The difference is, that without -ftree-vectorize the inner loop (do k = 1, 9)
is completely unrolled, but with vectorization
--- Comment #2 from dorit at il dot ibm dot com 2007-06-18 11:03 ---
I see this in the vectorizer dump file (with mainline from a few days ago):
(compute_affine_dependence
(stmt_a =
D.3027_19 = p_7-a[D.3026_18])
(stmt_b =
p_7-a[D.3025_17] = D.3027_19)
Data ref a:
(Data Ref:
stmt
--- Comment #4 from dorit at il dot ibm dot com 2007-06-18 11:08 ---
I see this in the vectorizer dump file (with mainline from a few days ago):
(compute_affine_dependence
(stmt_a =
D.1423_50 = (*a_49(D))[D.1422_48])
(stmt_b =
(*a_49(D))[D.1420_51] = D.1425_54)
Data ref a:
(Data
--- Comment #1 from dorit at il dot ibm dot com 2007-06-13 08:41 ---
Sorry about the breakage. Does it work for you if you change the testcase as
follows?:
Index: pr32224.c
===
--- pr32224.c (revision 125641)
+++ pr32224
--- Comment #4 from dorit at il dot ibm dot com 2007-06-12 17:46 ---
it's on my (long) todo list...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32309
--- Comment #4 from dorit at il dot ibm dot com 2007-06-07 18:40 ---
You're right. I'm testing this obvious patch:
Index: tree-vect-analyze.c
===
*** tree-vect-analyze.c (revision 125526)
--- tree-vect-analyze.c (working
--- Comment #5 from dorit at il dot ibm dot com 2007-06-06 08:33 ---
(In reply to comment #4)
(In reply to comment #3)
Probably something similar is required for the VEC_UNPACK_FLOAT_*_EXPR
tree-codes ?
But these tree-codes are already there:
sorry, I guess I was looking
--- Comment #3 from dorit at il dot ibm dot com 2007-06-06 03:28 ---
(In reply to comment #1)
veclower expands things when it wrongly concludes that they are not supported
by the target in vecor mode. For demotion/promotion/conversion kinda operations
this may be because it does
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
GCC build triplet: powerpc-linux
GCC host triplet: powerpc-linux
GCC target triplet: powerpc-linux
http://gcc.gnu.org
: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
GCC build triplet: spu
GCC host triplet: spu
GCC target triplet: spu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31945
: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31946
--- Comment #3 from dorit at il dot ibm dot com 2007-05-16 20:45 ---
(In reply to comment #2)
Here is what happens in the three loops that don't get vectorized:
(1) the loop in testvectdp2:
...
so the vectorizer is ok, except that in this case D.1437_32 doesn't seem to
be used
casts out
of loops
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm
--- Comment #8 from dorit at il dot ibm dot com 2007-05-09 07:14 ---
So I guess this should be handled somewhere else. I'll open a new
missed-optimization PR instead (not against PRE this time). thanks.
This is now PR31873
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25809
--- Comment #2 from dorit at il dot ibm dot com 2007-05-08 21:00 ---
Here is what happens in the three loops that don't get vectorized:
(1) the loop in testvectdp2:
This is the loop we analyze:
# prephitmp.192_37 = PHI storetmp.191_30(3), D.1443_42(5)
# i_1 = PHI 1(3), i_44(5
--- Comment #6 from dorit at il dot ibm dot com 2007-05-02 20:38 ---
patch: http://gcc.gnu.org/ml/gcc-patches/2007-05/msg00111.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31699
--- Comment #3 from dorit at il dot ibm dot com 2007-04-26 19:34 ---
Created an attachment (id=13450)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13450action=view)
patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31699
--- Comment #4 from dorit at il dot ibm dot com 2007-04-26 19:37 ---
I'm testing the attched patch. The problem is that we don't compute the peel
factor correctly (when peeling to align a store) when we have multiple
data-types in the loop (the computation assumes that VF is the number
--- Comment #4 from dorit at il dot ibm dot com 2007-04-27 05:44 ---
patch: http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01739.html
requires retesting on ia64 before I can commit it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31589
--- Comment #7 from dorit at il dot ibm dot com 2007-04-25 21:30 ---
Are you going to submit/install your patch?
yes, I'll go ahead and submit the patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31615
--- Comment #5 from dorit at il dot ibm dot com 2007-04-19 07:27 ---
(In reply to comment #4)
(In reply to comment #3)
But then I wonder why we don't see the same failure on ia64?
Because the failing part of the testcase is only done on ilp32 targets:
! { dg-final { scan-tree-dump
--- Comment #3 from dorit at il dot ibm dot com 2007-04-18 10:18 ---
Created dump file using -fdump-tree-vect-details
thanks. So I don't understand why we expect to version for 3 different
data-references, since there are only 2 in the loop that is vectorized. But
then I wonder why we
--- Comment #5 from dorit at il dot ibm dot com 2007-04-17 07:22 ---
Doing cast motion actually causes about 25 *more* failures in the vectorizer
testsuite.
I'm closing this as won't fix since it seems there was no other reason to do
this.
can you please send me the patch so that I
--- Comment #6 from dorit at il dot ibm dot com 2007-04-17 07:38 ---
can you please send me the patch so that I could look at this failures before
you close this PR?
I'm going over my inbox top down, so I just saw that you had laready sent the
patch... so I will look into it. (thanks
--- Comment #7 from dorit at il dot ibm dot com 2007-04-17 19:31 ---
so I will look into it.
(for reference: http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01103.html).
So I guess this should be handled somewhere else. I'll open a new
missed-optimization PR instead (not against PRE
--- Comment #2 from dorit at il dot ibm dot com 2007-04-17 20:10 ---
2 more are under investigation:
no-section-anchors-vect-69.c
vect-reduc-dot-u16a.c
In the first testcase, the vectorizer can only prove that the data reference in
the third loop is aligned on 8 bytes
--- Comment #1 from dorit at il dot ibm dot com 2007-04-18 06:42 ---
could you please provide the .vect dump file, as generated with
-fdump-tree-vect-details?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31615
--- Comment #4 from dorit at il dot ibm dot com 2007-04-14 09:38 ---
I think the only thing that really matters is that the loop is vectorized. I
don't think the alignment details are important checking, even on platforms
where they are relevant. So we should remove all scan-tree
--- Comment #4 from dorit at il dot ibm dot com 2007-04-03 19:56 ---
yes, this is indeed a known problem (I don't know if there's a PR open for it).
It is one of the tree-ifcvt enhancements that Victor was going to tackle for
4.3 (item (2.3) in http://gcc.gnu.org/wiki
--- Comment #6 from dorit at il dot ibm dot com 2007-04-03 20:22 ---
So I see Devang had sent a patch for this over a year ago:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00167.html
I don't know what ever happened to it.
Maybe you want to give it a try? (you may need to implement
--- Comment #8 from dorit at il dot ibm dot com 2007-04-03 20:46 ---
(In reply to comment #7)
Something like:
(define_insn_and_split altivec_dupmode
[(set (match_operand:V 0 register_operand v)
(vec_duplicate: (match_operand: 0 r)))
(clobber (match_operand:V 3
--- Comment #7 from dorit at il dot ibm dot com 2007-03-24 08:00 ---
patch: http://gcc.gnu.org/ml/gcc/2007-03/msg00918.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30784
: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
GCC build triplet: i386-linux
GCC host triplet: i386-linux
GCC target triplet: i386-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31333
codegen for vectorized induction with altivec
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot
--- Comment #4 from dorit at il dot ibm dot com 2007-03-14 12:13 ---
I also saw this on powerpc64, on a different testcase (vectorizing longs with
-m64). seems like constant propagation during dom3 propagates the vector
initializer into a BIT_FIELD_EXPR, which results in invalid gimple
--- Comment #5 from dorit at il dot ibm dot com 2007-03-14 12:29 ---
this is the testcase I have ICE-ing on powerpc64-yellowdog, when compiled with
-ftree-vectorize -maltivec -m64 -O2:
long stack_vars_sorted[32];
void partition_stack_vars (long stack_vars_num)
{
long si, n
--- Comment #5 from dorit at il dot ibm dot com 2007-03-05 20:15 ---
I'm travelling now, but can prepare a fix when I'm back (next week).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31041
--- Comment #8 from dorit at il dot ibm dot com 2007-02-21 19:31 ---
Is this acceptable ?
sure, thanks
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30858
--- Comment #6 from dorit at il dot ibm dot com 2007-02-20 22:56 ---
proposed patches - http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01734.html
I have thrown most of Suse Linux 10.3 at it and it has crashed
in a few places.
would you mind giving these patches a try? (to see what's
--- Comment #3 from dorit at il dot ibm dot com 2007-02-19 08:28 ---
Looks like possibly some bad interaction between vectorization of induction
and
vectorization of strided-access. Will investigate.
I looked into it with Ira, and looks like the problem is that during
--- Comment #2 from dorit at il dot ibm dot com 2007-02-19 12:45 ---
Reduced testcase:
int foo (int ko)
{
int j,i;
for (j = 0; j ko; j++)
i += (i 10) ? -5 : 7;
return i;
}
Looking into it...
--
dorit at il dot ibm dot com changed:
What|Removed
--- Comment #3 from dorit at il dot ibm dot com 2007-02-19 12:56 ---
(In reply to comment #0)
Thanks for exercising the vectorizer and reporting these bugs!
On the wider issue of the quality of the vectorizer, I
have thrown most of Suse Linux 10.3 at it and it has crashed
in a few
--- Comment #5 from dorit at il dot ibm dot com 2007-02-19 14:12 ---
Looks like I wasn't careful enough with my fix for PR30771. Here is a fix for
that fix I'm now testing:
Index: tree-vect-analyze.c
===
--- tree-vect
--- Comment #4 from dorit at il dot ibm dot com 2007-02-18 16:42 ---
patch: http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01555.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30795
--- Comment #2 from dorit at il dot ibm dot com 2007-02-18 21:50 ---
I was able to reproduce it. Here's a reduced testcase:
void dacP98FillRGBMap( unsigned char *pBuffer )
{
unsigned long dw, dw1;
unsigned long *pdw = (unsigned long *)(pBuffer);
for( dw = 256, dw1 = 0; dw
--- Comment #3 from dorit at il dot ibm dot com 2007-02-15 10:21 ---
I'll look into it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30795
--- Comment #3 from dorit at il dot ibm dot com 2007-02-12 10:11 ---
I'll look into it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30771
--- Comment #4 from dorit at il dot ibm dot com 2007-02-12 14:23 ---
I'm testing the patch below. (wasn;t able to reproduce the problem in the
attched testcase, but here's a reduced testcase for the problem that Richi
described - thanks!:
int a[128];
int
main()
{
short i;
for (i=0
--- Comment #11 from dorit at il dot ibm dot com 2007-02-06 08:18 ---
(In reply to comment #10)
One thing I can think of that this description misses is that the two
pointers must be based-on *different* restrict-qualified pointers, unless
that case is already handled elsewhere
--- Comment #8 from dorit at il dot ibm dot com 2007-01-07 20:22 ---
I'm testing this patch, that makes us more conservative, and concludes that two
pointers don't overlap only if both are based on restricted pointers, with
based on trivially implemented as the pointer used
--- Comment #16 from dorit at il dot ibm dot com 2006-12-12 20:59 ---
(In reply to comment #13)
Looks like what's blocking vectorization of the loop is:
sinc.f90:8: note: value used after loop.
sinc.f90:8: note: not vectorized: relevant stmt not supported: D.1408_32 =
(*radius_31)[D
--- Comment #11 from dorit at il dot ibm dot com 2006-12-07 20:19 ---
(In reply to comment #10)
Using the three patches:
...
gfortran is able to use sincos - and does so for my example (comment #0; the
example, however, cannot be vectorized).
why? (what does -fdump-tree-vect
--- Comment #12 from dorit at il dot ibm dot com 2006-12-06 22:22 ---
By the way, you wrote 2006-11-17:
Should be submitted this weekend
Any new ETA?
It was already submitted:
http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00110.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #7 from dorit at il dot ibm dot com 2006-11-17 06:46 ---
(In reply to comment #6)
This patch should fix the problem:
indeed it does, thanks!
are you going to submit it to mainline?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29779
at il dot ibm dot com
GCC build triplet: i?86-*-* and x86_64-*-*
GCC host triplet: i?86-*-* and x86_64-*-*
GCC target triplet: i?86-*-* and x86_64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29777
: unassigned at gcc dot gnu dot org
ReportedBy: dorit 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=29778
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
GCC build triplet: ppc*-*-linux
GCC host triplet: ppc*-*-linux
GCC target triplet: ppc*-*-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29779
--- Comment #2 from dorit at il dot ibm dot com 2006-11-09 20:26 ---
But these files can be succesfully vectorized using current (gcc version 4.3.0
20061109) version on i686:
gcc -O2 -msse2 -ftree-vectorize -fdump-tree-vect-all vect-widen-mult-sum.c
vect-widen-mult-sum.c:16: note
--- Comment #6 from dorit at il dot ibm dot com 2006-11-05 15:48 ---
(In reply to comment #5)
This was something that slipped in, IIRC. I was of Ian's viewpoint, that
may_alias_p should handle it, and it shouldn't be special to data-references.
yes, it was originally added
support in the vectorizer
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29269
vectorization
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
http://gcc.gnu.org
--- Comment #4 from dorit at il dot ibm dot com 2006-09-21 19:30 ---
By the way, the testcase gets vectorized if you compile with -fwrapv.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29170
--- Comment #4 from dorit at il dot ibm dot com 2006-09-11 10:57 ---
You could help by looking at the source code (there are only a few dozens
places mentioning flag_unsafe_math_optimizations) and auditing which places
would be more suited to a new flag_reassociate_fp variable.
we'd
--- Comment #9 from dorit at il dot ibm dot com 2006-08-31 08:08 ---
I have been unsuccessful in reproducing this problem on a i386-redhat-linux.
I don't get a failure compiling the testcase from comment 8.
I tried to compile the testcase from comment 7 and got the following errors
--- Comment #10 from dorit at il dot ibm dot com 2006-08-31 08:22 ---
I think this can be closed?
(I opened a missed-optimization PR instead - PR28643)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26969
--- Comment #12 from dorit at il dot ibm dot com 2006-09-01 05:43 ---
oops - I didn't notice it was open against 4.1.
So hopefully porting Victor's patch to 4.1 would fix it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26969
--- Comment #55 from dorit at il dot ibm dot com 2006-08-09 19:10 ---
Subject: Re: [4.0/4.1 Regression] gcc 4 produces worse x87 code
on all platforms than gcc 3
Here's some questions I need to figure out:
(1) Why do I have to throw the -funsafe-math-optimizations flag to
enable
--- Comment #3 from dorit at il dot ibm dot com 2006-08-08 07:38 ---
Err, SSA copy prop should be enough, actually, since after copy-prop,
the phi will have no users (and they shouldn't care about code with no
uses that doesn't access memory).
Though it's interesting
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
GCC build triplet: powerpc-linux
GCC host triplet: powerpc-linux
GCC target triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #25 from dorit at il dot ibm dot com 2006-08-07 07:09 ---
(In reply to comment #24)
Fixed, a new different bug for the missed optimization should be opened.
It's PR28628.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
--- Comment #43 from dorit at il dot ibm dot com 2006-08-07 20:35 ---
I'm all for this. info gcc says that w/o a guarantee of alignment, loops are
duped, with an if selecting between vector and scalar loops, is this not
accurate?
yes
I spent a day trying to get gcc to vectorize
: dorit at il dot ibm dot com
GCC build triplet: powerpc-linux
GCC host triplet: powerpc-linux
GCC target triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28643
--- Comment #19 from dorit at il dot ibm dot com 2006-07-23 19:03 ---
The fix we've agreed is best in principle is to speculatively increase
the DECL_ALIGN of vectorisable variables before compiling functions.
Dorit says that there is a patch related to this on the autovect branch
--- Comment #13 from dorit at il dot ibm dot com 2006-03-01 12:35 ---
So I'll submit the patch to gcc-patches for approval. Can someone please check
if this patch actually solves this PR?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26197
--- Comment #11 from dorit at il dot ibm dot com 2006-02-28 08:26 ---
Created an attachment (id=10935)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10935action=view)
tentative patch
I get a similar error message when trying to bootstrap mainline with
vectorization enabled:
/home
--- Comment #2 from dorit at il dot ibm dot com 2006-02-26 11:01 ---
For -ftree-vectorizer-verbose=1 the vectorizer reports each loop that got
vectorized, and also the total number of loops that got vectorized, even if
that number is zero. If preferable, we can report that 0 loops got
--- Comment #3 from dorit at il dot ibm dot com 2006-02-26 11:05 ---
patch: http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01905.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26419
--- Comment #3 from dorit at il dot ibm dot com 2006-02-21 22:01 ---
patch:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01710.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26359
--- Comment #3 from dorit at il dot ibm dot com 2006-02-21 22:02 ---
patch:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01713.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26360
--- Comment #1 from dorit at il dot ibm dot com 2006-02-20 16:45 ---
Looks like the vectorizer detects a strided access in this testcase. Strided
accesses are not entirely supported for SSE right now (work in progress...),
but it is enabled, so currently all strided testcases brake
--- Comment #2 from dorit at il dot ibm dot com 2006-02-20 17:09 ---
Actually there's this patch by rth that seems to fix this ICE; it's from a
while back, I don't think it was fully tested at the time, and I'm not sure it
provides all the missing bits/fixes for SSE support
--- Comment #2 from dorit at il dot ibm dot com 2006-02-19 08:50 ---
This happens because we actually rely on dce taking place after the vectorizer
to clean up dead code. When we detect a pattern (widneing-summation in this
case) we create a dummy stmt (pattern-stmt) that represents
--- Comment #2 from dorit at il dot ibm dot com 2006-02-19 15:34 ---
The problem is that during dce the call to is_hidden_global_store returns false
cause the tag is not marked as global/static.
This seems to fix it:
Index: tree-ssa-alias.c
--- Comment #10 from dorit at il dot ibm dot com 2006-02-19 16:10 ---
so maybe if an SFT has may-aliases then new_type_alias should add the
may-aliases of the SFT as may-aliases of the new tag, instead of adding the SFT
as a may-alias of the new tag. ?
There's a comment
--- Comment #6 from dorit at il dot ibm dot com 2006-02-13 16:23 ---
(In reply to comment #5)
Probably related to
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00446.html
Would you expect then that calling mark_new_vars_to_rename, like you did in
your patch, will fix this problem?
I
--- Comment #6 from dorit at il dot ibm dot com 2006-02-08 14:17 ---
(In reply to comment #4)
... This happens
because the IA-64 port defines the widen_ssumv4hi3 pattern. The IA-64 port is
the only one that defines this pattern, and hence is probably the only port
broken here. All
--- Comment #7 from dorit at il dot ibm dot com 2006-02-08 14:19 ---
(In reply to comment #5)
Will take care of that.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25918
--- Comment #1 from dorit at il dot ibm dot com 2006-01-26 09:07 ---
Can you please send the dump files generated by -fdump-tree-vect-details?
reduc-dot-s16.c needs the sdot_prodv4hi pattern, which is implemented for ia64,
so I'd expect one loop to be vectorized. I wonder what's
--- Comment #5 from dorit at il dot ibm dot com 2006-01-24 09:10 ---
Patch:
Index: tree-vect-patterns.c
===
--- tree-vect-patterns.c(revision 109954)
+++ tree-vect-patterns.c(working copy)
@@ -243,7 +243,8
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at il dot ibm dot com
GCC build triplet: ppc64-yellowdog-linux
GCC host triplet: ppc64-yellowdog-linux
GCC target triplet: ppc64-yellowdog
--- Comment #10 from dorit at il dot ibm dot com 2006-01-08 13:49 ---
Reopening since many of the intrinsics could still vectorize better.
Could help if you list specific functions that you expect to get vectorized. As
far as dotprod is concerned - if it's operating on floats, you
--- Comment #6 from dorit at il dot ibm dot com 2006-01-04 07:33 ---
Maybe related to:
2005-12-26 Kazu Hirata [EMAIL PROTECTED]
PR tree-optimization/25125
* convert.c (convert_to_integer): Don't narrow the type of a
PLUX_EXPR or MINUS_EXPR if !flag_wrapv
--- Comment #7 from dorit at il dot ibm dot com 2006-01-04 07:36 ---
(sorry, didn't notice it was already diagnosed as such)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25590
--- Comment #2 from dorit at il dot ibm dot com 2005-12-15 12:41 ---
The problem is that the vectorizer applies loop-peeling in order to align the
data reference *(m-c+i), and peeling only works correctly if the data is
naturally aligned (aligned on it's type size). This is what
--- Comment #3 from dorit at il dot ibm dot com 2005-12-15 12:50 ---
related discussion: http://gcc.gnu.org/ml/gcc/2005-12/msg00390.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25413
--- Comment #9 from dorit at il dot ibm dot com 2005-12-14 15:38 ---
Thanks for testing the patch. I finally submitted it:
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01071.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24378
1 - 100 of 200 matches
Mail list logo
