--- Comment #5 from dorit at gcc dot gnu dot org 2009-03-08 14:25 ---
This is a known problem... Indeed when Zdenek introduced predictive-commoning
there was a discussion on whether to schedule it before or after vectorization.
AFAIR, it ended up getting scheduled before the vectorizer
--- Comment #2 from dorit at gcc dot gnu dot org 2009-02-01 21:06 ---
(reminds me of a couple missed-optimization PRs where vectorization is also
failing due to casts - PR31873 , PR26128 - don't know if this is related)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39068
--- Comment #7 from dorit at gcc dot gnu dot org 2009-01-27 12:46 ---
related testcase/PR: PR37021
and related discussion: http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01322.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33113
--- Comment #9 from dorit at gcc dot gnu dot org 2009-01-27 12:40 ---
(In reply to comment #4)
> The testcase should be
> subroutine to_product_of(self,a,b,a1,a2)
> complex(kind=8) :: self (:)
> complex(kind=8), intent(in) :: a(:,:)
> complex(kind=8),
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37700
Product: gcc
Version: unknown
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at gcc do
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37698
l array read
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37695
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37694
D
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37693
unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at gcc dot gnu dot org
GCC build triplet: i386-linux
GCC host triplet: i386-linux
GCC target
--- Comment #4 from dorit at gcc dot gnu dot org 2008-09-26 06:29 ---
Subject: Bug 37574
Author: dorit
Date: Fri Sep 26 06:28:01 2008
New Revision: 140685
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140685
Log:
PR tree-optimization/37574
* tree-vect
--- Comment #3 from dorit at gcc dot gnu dot org 2008-09-21 13:18 ---
happens during outer-loop vectorization. I'm looking into it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37574
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dorit at gcc dot gnu dot org
|dot org
--- Comment #3 from dorit at gcc dot gnu dot org 2008-08-22 13:31 ---
(In reply to comment #2)
> The x86_64 generated code looks like
...
> I wonder why we do not use movups instead.
> t.i:3: note: Alignment of access forced using peeling.
> t.i:3: note: Peeling for align
--- Comment #2 from dorit at gcc dot gnu dot org 2008-08-19 07:15 ---
Subject: Bug 37152
Author: dorit
Date: Tue Aug 19 07:14:26 2008
New Revision: 139224
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139224
Log:
PR bootstrap/37152
* tree-vect-tra
--- Comment #1 from dorit at gcc dot gnu dot org 2008-08-18 20:11 ---
(In reply to comment #0)
> I just tried to compile GNU CC version 4.4 snapshot 20080815 with the
> Intel C compiler and it said
> gcc/tree-vect-transform.c(2488): warning #187: use of "=" where &
--- Comment #2 from dorit at gcc dot gnu dot org 2008-07-22 10:39 ---
(In reply to comment #1)
> One problem is vectorizable_conversion. Is there a way to support
> V4DF/V4DI <-> D4SI/V4SF
> V8SI <-> V8SF
With the current framework, the only way to support
--- Comment #1 from dorit at gcc dot gnu dot org 2008-02-25 10:21 ---
(In reply to comment #0)
> It is beneficial to unroll reduction loop (and split the reduction target) to
> reduce dependence height due to recurrence, but GCC does not perform such
> optimization (-O3
--- Comment #19 from dorit at gcc dot gnu dot org 2008-01-28 13:20 ---
> Fixed?
In a way, yes. The problem is avoided by generating too conservative code.
AFAIU, a better solution may be expected in 4.4 from the stack alignment
branch. In any case this segfault PR can be closed,
--- Comment #7 from dorit at gcc dot gnu dot org 2008-01-03 10:17 ---
fixed
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from dorit at gcc dot gnu dot org 2008-01-03 10:08 ---
(In reply to comment #5)
> I can confirm that pulseaudio 0.9.8 sources which caused the crash, compile
> fine now with the latest gcc 4.3 snapshot.
thanks. (I usually prefer to wait for the person who report
--- Comment #3 from dorit at gcc dot gnu dot org 2007-12-27 19:14 ---
Subject: Bug 34591
Author: dorit
Date: Thu Dec 27 19:14:17 2007
New Revision: 131206
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131206
Log:
PR tree-optimization/34591
* t
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dorit at gcc dot gnu dot org
|dot org
--- Comment #3 from dorit at gcc dot gnu dot org 2007-12-19 09:38 ---
> This is a vectorizer vs not being able to run may_alias after it
can you please remind me why we can't run may_alias after the vectorizer? (and
what do you think can be done about it?)
--
http://gcc
--- Comment #5 from dorit at gcc dot gnu dot org 2007-12-17 11:14 ---
Subject: Bug 34445
Author: dorit
Date: Mon Dec 17 11:13:56 2007
New Revision: 131006
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131006
Log:
PR tree-optimization/34445
* t
--- Comment #4 from dorit at gcc dot gnu dot org 2007-12-16 13:06 ---
testing this patch:
*** tree-vect-transform.c (revision 130987)
--- tree-vect-transform.c (working copy)
*** vect_estimate_min_profitable_iters (loop
*** 197,214
factor = 1
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dorit at gcc dot gnu dot org
|dot org
--- Comment #14 from dorit at gcc dot gnu dot org 2007-11-22 15:22 ---
closed, given recent feedback
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from dorit at gcc dot gnu dot org 2007-11-22 15:17 ---
(In reply to comment #12)
...
> > 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)?
...
>
--- Comment #14 from dorit at gcc dot gnu dot org 2007-11-22 15:14 ---
(In reply to comment #13)
> Dorit, can you please take a look again?
I will not be able to look into this in the next couple of weeks, sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33869
--- Comment #7 from dorit at gcc dot gnu dot org 2007-11-13 13:29 ---
fixed
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from dorit at gcc dot gnu dot org 2007-11-07 18:06 ---
(In reply to comment #0)
> Following testcase exposes optimization problem with current SVN gcc:
...
> the same address
> is accessed with unaligned access (3) as well as aligned access.
This is a missed-opt
--- Comment #4 from dorit at gcc dot gnu dot org 2007-11-06 18:29 ---
> We probably need to call the gimplifier (if we don't already) and also apply
> Zdenek's patch that allows gimplifying rhs cond_exprs -
> http://gcc.gnu.org/ml/gcc-patches/2007-07/msg02052.html.
--- Comment #3 from dorit at gcc dot gnu dot org 2007-11-06 18:11 ---
I don't think these are related to PR33680. Sounds like we may be generating a
stmt with a cond_expr at the rhs. The data-reference analysis results in:
base_address: &blocks
offset from bas
--- Comment #11 from dorit at gcc dot gnu dot org 2007-11-04 04:09 ---
(In reply to comment #10)
> Doesn't fail on trunk since r129797:
> 2007-10-31 Sebastian Pop <[EMAIL PROTECTED]>
> PR tree-optimization/32377
> ...
> before:
> pr27549.C:58: n
--- Comment #3 from dorit at gcc dot gnu dot org 2007-11-04 03:49 ---
Subject: Bug 33987
Author: dorit
Date: Sun Nov 4 03:48:58 2007
New Revision: 129880
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129880
Log:
PR tree-optimization/33987
* t
--- Comment #2 from dorit at gcc dot gnu dot org 2007-11-03 04:06 ---
testing this fix:
Index: tree-vect-transform.c
===
*** tree-vect-transform.c (revision 129763)
--- tree-vect-transform.c (working copy
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #6 from dorit at gcc dot gnu dot org 2007-11-01 00:55 ---
thanks!
> but the problem is that in the vectorizer, DR_STEP has to be an
> INTEGER_CST: for instance,
> step = TREE_INT_CST_LOW (DR_STEP (dra));
> ...
> || tree_int_cst_compare (DR_STEP (dra
--- Comment #3 from dorit at gcc dot gnu dot org 2007-10-31 17:46 ---
(In reply to comment #2)
> Works for me. Try a newer 4.2.x release.
I wonder if the fix for PR25413 fixed this problem - it went into 4.2 on July
25th, just shortly after 4.2.1 was released :-( but should be
--- Comment #17 from dorit at gcc dot gnu dot org 2007-10-30 05:25 ---
Subject: Bug 32893
Author: dorit
Date: Tue Oct 30 05:25:10 2007
New Revision: 129764
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129764
Log:
PR tree-optimization/32893
* tree-vec
--- Comment #5 from dorit at gcc dot gnu dot org 2007-10-23 19:50 ---
Subject: Bug 33860
Author: dorit
Date: Tue Oct 23 19:50:18 2007
New Revision: 129587
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129587
Log:
PR tree-optimization/33860
* t
--- Comment #5 from dorit at gcc dot gnu dot org 2007-10-23 03:24 ---
Subject: Bug 33835
Author: dorit
Date: Tue Oct 23 03:24:06 2007
New Revision: 129571
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129571
Log:
PR tree-optimization/33834
PR tree-opti
--- Comment #7 from dorit at gcc dot gnu dot org 2007-10-23 03:24 ---
Subject: Bug 33834
Author: dorit
Date: Tue Oct 23 03:24:06 2007
New Revision: 129571
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129571
Log:
PR tree-optimization/33834
PR tree-opti
--- Comment #4 from dorit at gcc dot gnu dot org 2007-10-22 22:54 ---
There's some bad interaction here between the data-interleaving support and the
outer-loop support - these are not yet supported together, however it still
slipped through the checks during the analysis phase.
--- Comment #4 from dorit at gcc dot gnu dot org 2007-10-22 04:37 ---
I'm testing a patch that would fix both this PR and PR33834 (posted it under
the PR33834 entry). By the way, this testcase does not get vectorized with
current mainline (an Oct21 snapshot) because the call to c
--- Comment #6 from dorit at gcc dot gnu dot org 2007-10-22 04:28 ---
I'm testing this patch. It fixes the two testcases, while allowing the first
testcase to get vectorized. (the last bit in the patch is the fix for PR33835):
Index: tree-vect-anal
--- Comment #3 from dorit at gcc dot gnu dot org 2007-10-21 08:07 ---
The proposed fix/work-around for PR33834 also happens to fix this PR. But the
real problem is that we try to access a NULL argument (operand 2 of a CALL_EXPR
may be NULL). So we should probably at least add something
--- Comment #5 from dorit at gcc dot gnu dot org 2007-10-21 07:14 ---
This patch fixes it:
Index: tree-vect-transform.c
===
*** tree-vect-transform.c (revision 129521)
--- tree-vect-transform.c (working copy
--- Comment #4 from dorit at gcc dot gnu dot org 2007-10-21 06:39 ---
I was able to reproduce this on i386-linux.
Looks like it's related to PLUS_EXPR vs. POINTER_PLUS_EXPR. The folowing patch
fixes this testcase:
Index: tree-vect-anal
--- Comment #35 from dorit at gcc dot gnu dot org 2007-10-15 05:52 ---
bootstrap with vectorization enabled with your patch applied passes for me on
ppc64-linux. thanks!!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32582
--- Comment #16 from dorit at gcc dot gnu dot org 2007-10-03 18:52 ---
Ryan, thanks a lot for the info. FYI, I started a discussion about this here:
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00202.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32893
--- Comment #7 from dorit at gcc dot gnu dot org 2007-09-19 14:28 ---
(In reply to comment #6)
> It looks like
> zlib compiled w/ -O -msse -ftree-vectorize (built with fedora's rpm package
> gcc-4.1.2-17)
> has same problem.
> In my environment, rpm-4.4.2.1-7.fc8 a
--- Comment #5 from dorit at gcc dot gnu dot org 2007-09-14 20:53 ---
(In reply to comment #4)
> Very similar testcase with the difference that it is not fixed by r128415 and
> makes current trunk segfault in VEC_tree_base_pop():
> void f (unsigned int *d, unsigned int
--- Comment #7 from dorit at gcc dot gnu dot org 2007-09-14 18:49 ---
(In reply to comment #6)
> I can bootstrap current trunk (r128479) with -ftree-vectorize on
> x86_64-unknown-linux-gnu for some time now, and, according to
> http://gcc.gnu.org/ml/gcc-patches/2007-09/msg0
--- Comment #3 from dorit at gcc dot gnu dot org 2007-09-12 07:10 ---
Subject: Bug 33373
Author: dorit
Date: Wed Sep 12 07:09:38 2007
New Revision: 128415
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128415
Log:
PR tree-optimization/33373
* tree-vect
--- Comment #2 from dorit at gcc dot gnu dot org 2007-09-10 09:08 ---
Testing this patch (it's a bug in the fix for PR33301. I accidentally treated
TYPE_SIZE_UNIT as a constant, whereas it's really a tree...):
Index: tree-vect
--- Comment #2 from dorit at gcc dot gnu dot org 2007-09-08 09:42 ---
(In reply to comment #1)
> (In reply to comment #0)
> > When the testcase gcc.dg/tree-ssa/predcom-3.c is compiled with
> > vectorization it
> > ICes when the dataref analysis called from vectoriz
--- Comment #6 from dorit at gcc dot gnu dot org 2007-09-08 09:24 ---
fix committed
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #2 from dorit at gcc dot gnu dot org 2007-09-08 09:23 ---
fix committed
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #1 from dorit at gcc dot gnu dot org 2007-09-08 09:19 ---
Subject: Bug 33301
Author: dorit
Date: Sat Sep 8 09:19:39 2007
New Revision: 128265
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128265
Log:
PR tree-optimization/33301
* tree-vect
--- Comment #5 from dorit at gcc dot gnu dot org 2007-09-07 15:00 ---
Subject: Bug 33299
Author: dorit
Date: Fri Sep 7 15:00:11 2007
New Revision: 128242
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=128242
Log:
PR tree-optimization/33299
* t
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at gcc dot gnu dot org
GCC build triplet: i386-linux
GCC host triplet: i386-linux
GCC target triplet: i386-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33320
l
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at gcc dot gnu dot org
GCC build triplet: powerpc-linux
GCC host triplet: powerpc-linux
GCC target triplet: powerpc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33319
--- Comment #4 from dorit at gcc dot gnu dot org 2007-09-04 19:14 ---
(by the way, fast-math should not be required here, but that's a different
bug... will fix that soonish)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33299
--- Comment #3 from dorit at gcc dot gnu dot org 2007-09-04 19:11 ---
I'm testing this patch:
Index: tree-vect-transform.c
===
*** tree-vect-transform.c (revision 128037)
--- tree-vect-transform.c (working
fprintf (vect_dump, "get vectype for scalar type: ");
--
Summary: wrong vectorization factor due to an invariant type-
promotion in the loop
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dorit at gcc dot gnu dot org
|dot org
--- Comment #2 from dorit at gcc dot gnu dot org 2007-09-04 11:44 ---
(In reply to comment #1)
> Confirmed. It looks like the vectorizer forgets to update the PHI node for
> stmp_var:
yes. I suspect I didn't expect at the time that there would be two
loop-closed-ssa-form p
--- Comment #3 from dorit at gcc dot gnu dot org 2007-08-31 14:18 ---
(In reply to comment #2)
> Subject: Re: Missed opportunities for vectorization due to invariant
> condition
> > Looks like -fno-tree-pre is not enough, because if PRE doesn't do it, then
> >
--- Comment #3 from dorit at gcc dot gnu dot org 2007-08-31 13:57 ---
...
> This is due to data ref analysis problems:
> ./fatigue.f90:14: note: not vectorized: data ref analysis failed
> (*stress_tensor.0_16)[D.1508_168] = D.1513_173
> ./fatigue.f90:14: note: bad data refer
--- Comment #1 from dorit at gcc dot gnu dot org 2007-08-31 13:39 ---
(In reply to comment #0)
> The innermost loop in "j" cannot be vectorized because of the
> irregular code in that loop, i.e. the condition "IF ( l.NE.k )". But
> the cond expression is i
--- Comment #5 from dorit at gcc dot gnu dot org 2007-08-30 16:29 ---
> dorit,
> i am having trouble exactly reproducing this example because you did not
> give the svn revision and so all of the numbers are a little bit
> different.
it's revision 127623
> Ho
--- Comment #2 from dorit at gcc dot gnu dot org 2007-08-30 10:12 ---
> There are two time consuming routines in air.f90 of the Polyhedron
> benchmark that are not vectorized: lines 1328 and 1354. These appear
> in the top counting of execution time with oprofile:
>
>
--- Comment #3 from dorit at gcc dot gnu dot org 2007-08-30 08:12 ---
(In reply to comment #2)
> I suspect this might be due to not updating the rd information after
> unrolling.
> Can you check if
> analyze_insns_in_loop() (which calls df_analyze()) is being called just
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dorit at gcc dot gnu dot org
|dot org
--- Comment #1 from dorit at gcc dot gnu dot org 2007-08-29 09:08 ---
I accidentally entered this bug twice. I'm closing this one, and will use
PR33224 instead.
--
dorit at gcc dot gnu dot org changed:
What|Removed |
--- Comment #1 from dorit at gcc dot gnu dot org 2007-08-29 09:04 ---
> In the testcase below, after the inner-loop gets completely unrolled, the
> enclosing i-loop does not get unrolled because of failure to analyze the loop
> iv, possibly due to a bug in df:
...
> Comp
zation
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at gcc dot gnu dot org
GCC build triplet: powerpc64-linux
GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33224
zation
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at gcc dot gnu dot org
GCC build triplet: powerpc64-linux
GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33222
--- Comment #10 from dorit at gcc dot gnu dot org 2007-08-26 07:49 ---
(In reply to comment #9)
> I've confirmed that the problem is caused by '-ftree-vectorize' passed to
> compile gcc. More precisely, a 'movdqa' instruction in constraint_operands()
--- Comment #2 from dorit at gcc dot gnu dot org 2007-08-20 05:55 ---
> Making us return symbolic stride would not be hard. The problem is that data
> dependence analysis would fail anyway,
sometimes (not in this testcases) there won't be a need for dependence testi
--- Comment #6 from dorit at gcc dot gnu dot org 2007-08-19 13:47 ---
> Sebastian - any thughts/plans?
Here's another testcase:
subroutine sub(aa,bb,n,m)
implicit none
integer, intent(in) :: n,m
real, intent(inout) :: aa(n,m)
real, intent(in):: bb(n,m)
integer ::
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dorit at gcc dot gnu dot org
GCC build triplet: powerpc64-linux
GCC host triplet: powerpc64-linux
GCC target trip
--- Comment #5 from dorit at gcc dot gnu dot org 2007-08-14 20:47 ---
Additional testcases:
(1) see loop in lines 23 and 32 in
http://gcc.gnu.org/ml/gcc-help/2007-08/msg00171.html
(2)
> SUBROUTINE SUSCEP(L,Iz)
> IMPLICIT NONE
> INTEGER L , Iz(L,L) , iznu
--- Comment #9 from dorit at gcc dot gnu dot org 2007-08-14 20:17 ---
PR32824 discusses a similar issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25621
--- Comment #5 from dorit at gcc dot gnu dot org 2007-08-01 11:57 ---
Ryan, I wonder what happens if you force alignment in the source code, like so:
unsigned short count[MAXBITS+1] __attribute__ ((__aligned__(16))) ;
In this case the vectorizer does not change the alignment of
--- Comment #4 from dorit at gcc dot gnu dot org 2007-08-01 11:36 ---
Also just for the record - the testcase for this PR is here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25413#c14
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32893
--- Comment #24 from dorit at gcc dot gnu dot org 2007-08-01 10:08 ---
> I do; however, I got stuck with another bootstrap problem at the moment
> (vectorization changes alignment of variables, which causes a
> misscompilation of crtend.o on my machine;
I wonder if this is r
--- Comment #3 from dorit at gcc dot gnu dot org 2007-07-28 21:03 ---
(In reply to comment #2)
> > Andrew, makes sense to you?
> I think my patch only checks PREFERRED_STACK_BOUNDARY and not STACK_BOUNDARY
> which is why it does not work but I have not looked into it at
--- Comment #8 from dorit at gcc dot gnu dot org 2007-07-28 19:20 ---
> v0 (and v10 are scratch registers and not saved.
so does it look like a register allocation bug then?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32582
--- Comment #1 from dorit at gcc dot gnu dot org 2007-07-25 20:43 ---
thanks a lot for checking both patches!
> With this patch zlib appears to compile successfully. The loop is
> vectorized with an "alignment of access forced using peeling" note and linked
> apps
--- Comment #21 from dorit at gcc dot gnu dot org 2007-07-25 11:11 ---
> Of course after my patch for PR 16660, the patch here should be
> changed to just return true always.
In this case, Ryan, could you please also try to see if Andrew's patch
(http://gcc.gnu.org/ml/gcc-p
--- Comment #19 from dorit at gcc dot gnu dot org 2007-07-25 08:52 ---
problem fixed.
--
dorit at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #18 from dorit at gcc dot gnu dot org 2007-07-25 08:51 ---
Subject: Bug 25413
Author: dorit
Date: Wed Jul 25 08:51:12 2007
New Revision: 126904
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126904
Log:
2007-07-25 Dorit Nuzman <[EMAI
--- Comment #17 from dorit at gcc dot gnu dot org 2007-07-25 08:40 ---
This looks like an unrelated problem - the vectorizer does not perform loop
peeling here so it's not an issue of natural alignment. Lets open a separate PR
for this one, unless there's already one op
--- Comment #3 from dorit at gcc dot gnu dot org 2007-07-24 13:05 ---
(In reply to comment #1)
> ... We actually had both options in the vectorizer for a while
> (guarded by ADJUST_IN_EPILOG hard-coded #define), however we didn't know how
> to
> choose between the
--- Comment #13 from dorit at gcc dot gnu dot org 2007-07-24 09:05 ---
David, can you confirm that this PR can now be closed?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25413
--- Comment #4 from dorit at gcc dot gnu dot org 2007-07-24 08:59 ---
Just for the record - as we discussed last week, there are two ways to solve
this problem - either have LIM leave behind it cleaner code (smthing like
copy-prop + dce to eliminate the extra copy stmts), or improve the
1 - 100 of 144 matches
Mail list logo
