--- 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
--- 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/msg
--- 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 unr
--- 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 #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:
(Da
--- 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.
--- 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 gues
--- 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 not
ersion: 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 com
GCC build triplet: powerpc-linux
GCC host triplet: powerpc-linux
GCC targe
--- 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
normal
Priority: P3
Component: 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
AssignedTo: 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
--- 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
ut
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 d
--- 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
# i_1 = PHI <1(3), i_44(5)>
:;
D.1437_32
--- 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 #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 #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
--- 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=13450&action=view)
patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31699
--- 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:
> ! {
--- 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 wo
--- 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 #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 #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 aga
--- 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 l
--- 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 pleas
--- 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
--- 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_dup"
> [(set (match_operand:V 0 "register_operand" "v")
> (vec_duplicate: (match_operand:
--- 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 implemen
--- 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.gn
verity: 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/bugzilla/show_bug.cgi?id=31334
Status: UNCONFIRMED
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: i386-linux
GCC host triplet: i386-linux
GCC target triplet: i386-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31333
--- 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
--- 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 #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-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
--- 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
===
---
--- 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
--- 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|R
--- 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 th
--- 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 =
--- 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 #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 #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;
--- 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 #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
--- 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 implemen
--- 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_
--- 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-
--- 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.
--- 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
--- 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-m
ity: normal
Priority: P3
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
AssignedTo: 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
ot org
ReportedBy: dorit 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
--- 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 origi
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/bugzilla/show_bug.cgi?id=29269
nment
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 i
--- 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
Summary: missed optimization: redundant casts prevent
vectorization
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot o
--- 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
--- 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 #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 #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 e
--- 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-optimiz
--- 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&#
: 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 #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 try
--- 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
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 #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 a
--- 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=10935&action=view)
tentative patch
I get a similar error message when trying to bootstrap mainline with
vectorization
--- 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 #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-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 #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 #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/f
--- 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 on
--- 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 comme
--- 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 #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&qu
--- 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 p
--- 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 #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
> &
--- 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&
--- 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
ty: 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-linux
http://g
--- 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 flo
--- 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 #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
--- 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 #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
--- 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
