> Hi,
>
> I have a project in mind which I'm going to propose to the GCC in terms
of
> Google Summer of Code. My project is not on the list of project ideas
> (http://gcc.gnu.org/wiki/SummerOfCode) that is why it would be very
> interesting
> for me to hear any opinions and maybe even to find a men
Grigori Fursin and Dorit Nuzman
(GROW'10 organizers)
ch capabilities of GCC
Organizers
Grigori Fursin, INRIA, France
Dorit Nuzman, IBM, Israel
Program Committee
Arutyun I. Avetisyan, ISP RAS, Russia
Zbigniew Chamski, Infrasoft IT Solutions, Poland
Albert Cohen, INRIA, France
David Edelsohn, IBM, USA
Bjorn Franke
> Steven Bosscher
> Sent by: gcc-ow...@gcc.gnu.org
>
> 30/11/2009 09:01
>
> To
>
> Daniel Berlin
>
> cc
>
> Richard Guenther , Toon Moene
> , gcc mailing list
>
> Subject
>
> Re: Caused by unknown alignment, was: Re: On the x86_64, does one
> have to zero a vector register before filling it comp
...
>
> >
> > I'm contemplating adding a tree- and gimple-level VEC_PERMUTE_EXPR of
> > the form:
> >
> >VEC_PERMUTE_EXPR (vlow, vhigh, vperm)
> >
> > which would be exactly equal to
> >
> >(vec_select
> > (vec_concat vlow vhigh)
> > vperm)
> >
> > at the rtl level. I.e. vperm is
'd definitely lobby for
it... do you know which of the polyhedron benchmarks have this issue,
and/or which other benchmarks suffer from it?)
Thanks for the reminder...
dorit
> >From: Dorit Nuzman
> >Date: Tue, 12 Aug 2008 14:48:07 +0300
> >X-MIMETrack: Serialize by Router
er 13, 2009
Decision notification: December 14, 2009
Workshop: January 23, 2010 half-day
Organizers ,
Grigori Fursin, INRIA, France
Dorit Nuzman, IBM, Israel
Program Committee
Arutyun I. Avetisyan, ISP RAS, Russia
Zbigniew Chamski, Infrasoft IT Solutions, Poland
Albert
> On Thu, Oct 16, 2008 at 1:05 AM, Steve Ellcey <[EMAIL PROTECTED]> wrote:
> > Dan and Richard,
> >
> > Are either of you aware of the gcc.dg/vect/vect-67.c failure that is
> > occuring on some platforms? I see it on IA64 (Linux and HP-UX) but a
> > scan of the gcc-testresults mailing lists shows
>Can anyone explain the relationship between the current vectorization
> optimizations in the gcc trunk compiler and the new -floop-strip-mine,
> -floop-interchange and -floop-block loop optimizations? Which takes
> precedence and does one set block the other in any way? I would hope
> that the
[i-1] in the second statement.
...which is exactly why loop distribution could make this loop (partially)
vectorizable - separating the first and second statements into separate
loops would allow vectorizing the first of the two resulting loops (which
is probably what icc does - icc reports that this lo
Dorit Nuzman/Haifa/IBM wrote on 03/01/2008 18:53:25:
> > g++-4.3 seems well ahead of other compilers in ability to vectorize STL
> > iterators:
> >
http://softwarecommunity.intel.com/Wiki/HighPerformanceComputing/688.htm
> >
> good to know.
> I browsed over th
> Richard,
>Will gcc 4.3.0's release be held up until all of the major
> architectures have fully optimized cost models for vectorization?
> I ask because as far as I can tell the powerpc cost model changes
> haven't been submitted yet.
At this point it doesn't look like there will be any cost
> Hi,
>
> I've noticed that GCC doesn't like to vectorize my loop.
>
> 1. When the loop has non-unit stride, I get 'complicated access pattern'
> message. Are non-unit strides supported?
>
> res(1:nS) = grid(1:(43-1)*7+1:7)*Dummy ! COMPLICATED ACCESSPATTERN
>
Currently only power-of-2 strides are
>
> From the last GCC Summit we learned about (Fortran) Frontend Based
> Optimizations from Toon and it was suggested to tackle one issue by
> promoting arrays to a first-class middle-end type. Discussion with
> Sebastian also reveals that this makes sense to ease the analysis
> of the into-GRAPHI
> Ira Rosen wrote:
> > Here is the link to the vectorizer's documentation:
> > http://gcc.gnu.org/projects/tree-ssa/vectorization.html
> >
> >
> >
> Thanks, but I take what it says there with some grains of salt.
?? please report any inaccuracies/outdated information you find, I'd like
to fix any
if (th && vect_print_dump_info (REPORT_COST))
fprintf (vect_dump, "Vectorization may not be profitable.");
return th;
--- tree-vectorizer.h 2007-12-16 16:08:07.0 +0200
+++ tree-vectorizer.cost_verbose.h 2007-12-16 16:08:02.0 +0200
@@ -73,6 +73,7 @@
REPORT_NONE,
REPORT_VECTORIZED_LOOPS,
REPORT_UNVE
> Sebastian,
>
> Here are (attached) results for testing HIRLAM with and without
> -ftree-loop-linear.
>
> As you can see, the results are neutral: 4 loops fewer vectorized, but
> about 50 fewer recognized.
>
any chance you kept the dumps and can report which loops were not
vectorized/recognized
> Uros Bizjak wrote:
>
> >> note: not vectorized: vectorization may not beprofitable.
> >
> > This is due to switching on vector cost model by default for x86.
>
> Ah, but my hidden critique of the message was:
> -ftree-vectorizer-verbose=2 should *only* tell us:
>
> 1. Which loops are vectorized.
> L.S.,
>
> I noticed some unexpected progress last night (as opposed to about a
> week ago).
>
> Previous figures:
>
> 5316 loops vectorized
> 6060 loops not vectorized
>
> New figures:
>
> 5188 loops vectorized
> 6189 loops not vectorized
>
> i.e., 201 loops *more* recognized by the vectorizer, o
> In August, I wrote the following about vectorized / not vectorized loops
> in HIRLAM
> (see http://hirlam.org):
>
> > $ grep 'LOOP VECTORIZED' HL_Prepare_00.html | wc -l
> > 3273
> > $ grep 'not vectorized' HL_Prepare_00.html | wc -l
> > 7845
>
> Yesterday, I performed a test with gcc-trunk-129
Zdenek's patch here -
http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02291.html - solved the
problem.
Kenny, Zdenek - many thanks for solving this issue!
dorit
> "Seongbae Park (박성배, 朴成培)" <[EMAIL PROTECTED]> wrote on
> 29/08/2007 01:01:42:
>
> > On 8/28/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
"Seongbae Park (박성배, 朴成培)" <[EMAIL PROTECTED]> wrote on
29/08/2007 01:01:42:
> On 8/28/07, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> ...
> > that obviously is not the case here, though. Do you (or someone else
> > responsible for df) have time to have a look at this problem?
> > Otherwise, we ma
Hi,
I have a question about a loop that when vectorized does not get unrolled
(by the rtl-level unroller), whereas the same loop when not vectorized does
get unrolled. This is the testcase:
#define N 40
#define M 10
float in[N+M], coeff[M], out[N];
void fir (){
int i,j,k;
float diff;
for (
> Jack Howarth has reported vect failures at -m64 on darwin with gfortran:
>
> http://gcc.gnu.org/ml/fortran/2007-08/msg00041.html
>
> I see the same kind of failures with gcc 4.3.0 revision 127178:
>
My guess is it's related to the recent patch that does not allow peeling on
64bit darwin (http://
Please find the summary of the loop optimizations BOF here:
http://gcc.gnu.org/wiki/LoopOptimizationsBOF.
We've also updated the Vectorizer Todo wiki page
(http://gcc.gnu.org/wiki/VectorizationTasks) and the Loop Optimizations
wiki page (http://gcc.gnu.org/wiki/LoopOptTasks).
Thanks to everyone
> Steve Kargl <[EMAIL PROTECTED]> wrote on 05/07/2007
> 17:46:45:
>
> > On Thu, Jul 05, 2007 at 12:48:38PM +0300, Dorit Nuzman wrote:
> > > Revital1 Eres/Haifa/IBM wrote on 05/07/2007 12:12:40:
> > >
> > > > > checking whether the GNU Fortra
Steve Kargl <[EMAIL PROTECTED]> wrote on 05/07/2007
17:46:45:
> On Thu, Jul 05, 2007 at 12:48:38PM +0300, Dorit Nuzman wrote:
> > Revital1 Eres/Haifa/IBM wrote on 05/07/2007 12:12:40:
> >
> > > > checking whether the GNU Fortran compiler is working... no
> &g
Revital1 Eres/Haifa/IBM wrote on 05/07/2007 12:12:40:
> > checking whether the GNU Fortran compiler is working... no
> > configure: error: GNU Fortran is not working; please report a bug in
> > http://gcc.gnu.org/bugzilla, attaching
> > /Develop/mainline-dn/build3/powerpc64-unknown-linux-
> gnu/li
I'm seeing this failure with several recent revisions from the last day or
two:
...
checking whether the GNU Fortran compiler is working... no
configure: error: GNU Fortran is not working; please report a bug in
http://gcc.gnu.org/bugzilla, attaching
/Develop/mainline-dn/build3/powerpc64-unknown-
Giovanni Bajo <[EMAIL PROTECTED]> wrote on 18/06/2007 15:06:48:
> On 6/18/2007 1:26 PM, Dorit Nuzman wrote:
>
> > these 3 are actually not so simple... the main thing that's blocking 2
of
> > them right now is that they need support for stores with gaps, which
can
>
> > However, as far as I know (also from talking with the
> > SLP authors) pretty much all the opportunities they had found at the
time
> > were in loops.
>
> I can hand you more than the testcases i've given so far. There is
> tons of code out there that would benefit from straight line
Inter
Giovanni Bajo <[EMAIL PROTECTED]> wrote on 17/06/2007 20:43:15:
> Hi Dorit,
>
> some years ago I posted these testcases to Bugzilla's GCC:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18437
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18438
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18439
>
>
Tim Prince <[EMAIL PROTECTED]> wrote on 17/06/2007 19:47:10:
> [EMAIL PROTECTED] wrote:
> > Tim Prince <[EMAIL PROTECTED]> wrote on 17/06/2007 04:15:56:
> >
> >> [EMAIL PROTECTED] wrote:
> >>> On Sat, Jun 16, 2007 at 06:54:46PM +0300, Dorit Nuzman w
"Daniel Berlin" <[EMAIL PROTECTED]> wrote on 17/06/2007 18:18:19:
...
>
> The whole purpose of SLP was to enable straight line code
> vectorization outside of loops.
I wouldn't say that's the whole purpose of SLP. I think the purpose and
beauty of SLP is that it's a simple algorithm that makes ve
> Dorit Nuzman wrote:
> >> H. J. Lu wrote:
> >>
> >>> Why don't we turn on vectorizer at -O3 or even -O2, depending on
> >>> ISA? I added -ftree-vectorize to BOOT_CFLAGS on x86-64. According to
> >>> -ftree-vectorizer-verbose=1, t
> H. J. Lu wrote:
>
> > Why don't we turn on vectorizer at -O3 or even -O2, depending on
> > ISA? I added -ftree-vectorize to BOOT_CFLAGS on x86-64. According to
> > -ftree-vectorizer-verbose=1, there are 82 loops vectorized in
> > gcc source. There are no regressions. There are not much changes
>
Tim Prince <[EMAIL PROTECTED]> wrote on 17/06/2007 04:15:56:
> [EMAIL PROTECTED] wrote:
> > On Sat, Jun 16, 2007 at 06:54:46PM +0300, Dorit Nuzman wrote:
> >>> There are quite a few known simple cases which vectorizer fails to
> >>> vectorize.
> &g
> On Fri, Jun 15, 2007 at 11:33:52PM -0400, Vladimir N. Makarov wrote:
> > H. J. Lu wrote:
> >
...
> > >
> > >
> > A mount ago I did some measurements of the effect of the vectorizer for
> > Core2 in 64-bit mode. Unfortunately, I saw small improvement (as I
> > remember less than 1% for SPECInt20
> H. J. Lu wrote:
>
> >On Fri, Jun 15, 2007 at 06:21:53PM -0700, Ian Lance Taylor wrote:
> >
> >
> >>This is hardly a new thought, but I believe that for the i386 gcc is
> >>handicapped by reload. No matter how smart we are before reload, it
> >>just take one poor decision by reload in an inner lo
> On Fri, Jun 15, 2007 at 06:21:53PM -0700, Ian Lance Taylor wrote:
> >
> > This is hardly a new thought, but I believe that for the i386 gcc is
> > handicapped by reload. No matter how smart we are before reload, it
> > just take one poor decision by reload in an inner loop and we've lost
> > all
David Edelsohn <[EMAIL PROTECTED]> wrote on 30/05/2007 04:21:15:
>I am pleased to announce that the GCC Steering Committee has
> appointed Dorit Nuzman, Richard Guenther, and Zdenek Dvorak as
> Auto-Vectorizer maintainers.
>
>Please join me in congratulating Dorit, R
"H. J. Lu" <[EMAIL PROTECTED]> wrote on 24/04/2007 01:03:25:
...
>
> There are
>
> [EMAIL PROTECTED] vect]$ cat pmovzxbw.c
> typedef unsigned char vec_t;
> typedef unsigned short vecx_t;
>
> in
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31667
>
By the way, this PR says "Integer externsions ar
"H. J. Lu" <[EMAIL PROTECTED]> wrote on 23/04/2007 21:56:37:
...
> > > > > > so this looks like a vec_unpacku_hi_v4si (or _lo?), i.e. what
is
> > now
> > > > > > modeled as follows in sse.md:
> > > > > >
> > > > > > (define_expand "vec_unpacku_hi_v4si"
> > > > > > [(match_operand:V2DI 0 "registe
"H. J. Lu" <[EMAIL PROTECTED]> wrote on 23/04/2007 01:34:39:
> On Mon, Apr 23, 2007 at 12:55:26AM +0300, Dorit Nuzman wrote:
> > "H. J. Lu" <[EMAIL PROTECTED]> wrote on 23/04/2007 00:29:16:
> >
> > > On Sun, Apr 22, 2007 at 11:14:20
"H. J. Lu" <[EMAIL PROTECTED]> wrote on 23/04/2007 00:29:16:
> On Sun, Apr 22, 2007 at 11:14:20PM +0300, Dorit Nuzman wrote:
> > "H. J. Lu" <[EMAIL PROTECTED]> wrote on 20/04/2007 18:02:09:
> >
> > > Hi Dorit,
> > >
> >
"H. J. Lu" <[EMAIL PROTECTED]> wrote on 20/04/2007 18:02:09:
> Hi Dorit,
>
> SSE4 has vector zero/sign-extensions like:
>
> (define_insn "sse4_1_zero_extendv2siv2di2"
> [(set (match_operand:V2DI 0 "register_operand" "=x")
> (zero_extend:V2DI
>(vec_select:V2SI
>
Thanks Tim for sending the dump files!
> for this one:
> > FAIL: gcc.dg/vect/pr30771.c scan-tree-dump-times vectorized 1 loops 1
>
> there should be { target vect_unpack } added to the check. i.e.:
> - /* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } }
*/
> + /* { dg-final { sc
...
> laST_UPDATED: Obtained from SVN: trunk revision 123799
>
> Native configuration is ia64-unknown-linux-gnu
>
> === gcc tests ===
>
>
for this one:
> FAIL: gcc.dg/vect/pr30771.c scan-tree-dump-times vectorized 1 loops 1
there should be { target vect_unpack } added to the check. i.e.:
-
> FX Coudert wrote:
> > Hi all,
> >
> > I reviewed this afternoon the postings from the gcc-testresults
> > mailing-list for the past month, and we have a couple of gfortran
> > testsuite failures showing up on various targets. Could people with
> > access to said targets (possibly maintainers) ple
> On 3/14/07, Dorit Nuzman <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > We have a '{2,2}' expression (vector initializer) propagated by dom
into a
> > BIT_FIELD_REF:
> >
> > before (bug.c.105t.vrp2):
> >
> > vect
Hi,
We have a '{2,2}' expression (vector initializer) propagated by dom into a
BIT_FIELD_REF:
before (bug.c.105t.vrp2):
vector long int vect_cst_.47;
vect_cst_.47_66 = {2, 2};
D.2103_79 = BIT_FIELD_REF ;
after (bug.c.106t.dom3):
"
Optimizing block #7
Optimi
>
> I've been trying to keep the GCC_4.3_Release_Planning wiki page up to
> date, and I'd like to be sure I haven't missed anything going in. I've
> moved several projects to the Completed section, and if I've done
> anything in error there, please correct it.
>
> So here's a survey of what's left
t DDR_DIST_VECTS).
dorit
> Jiahua
>
>
> 2007/2/12, Dorit Nuzman <[EMAIL PROTECTED]>:
> > > Thanks! In fact, I should ask how to deal with idiom (such as
> > > reduction, induction) recognition for virtual defs/uses.
> > >
> >
> > Just
> Hi,
>
> while playing with gcc-4.3 rev. 121994, i encountered a problem with
> autovectorisation.
>
> In the following simple code, the inner loop of c1() becomes vectorized
as
> expected, but the inner loop of c2() not because of
>
>test2.c:15: note: = analyze_loop_nest =
>test2.
> Thanks! In fact, I should ask how to deal with idiom (such as
> reduction, induction) recognition for virtual defs/uses.
>
Just curious - what is this for? (are you interested in this in the context
of vectorization? is there a specific example you have in mind?)
dorit
> Jiahua
>
>
> 2007/2/12
> On 2/12/07, Jiahua He <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I am reading the code of autovect branch and curious about how to deal
> > with the dependencies of virtual defs/uses. In the function
> > vect_analyze_scalar_cycles( ), I found the statement "Skip virtual
> > phi's. The data depend
Ayal Zaks/Haifa/IBM wrote on 07/02/2007 23:17:54:
> ...
>
> >Ah, right... I wonder if we can keep the loop structure in place, even
> >after completely unrolling the loop - I mean the 'struct loop' in
> >'current_loops' (not the actual CFG), so that the "SLP in loops" would
have
> >a chance to at
Ira Rosen/Haifa/IBM wrote on 06/02/2007 11:49:17:
> Dorit Nuzman/Haifa/IBM wrote on 05/02/2007 21:13:40:
>
> > Richard Guenther <[EMAIL PROTECTED]> wrote on 05/02/2007 17:59:00:
> >
...
> >
> > That's going to change once this project goes in: "(3.
> Hi Richard,
>
>
...
> However...,
>
> I have seen cases in which complete unrolling before vectorization
enabled
> constant propagation, which in turn enabled significant simplification of
> the code, thereby, in fact making a previously unvectorizable loop (at
> least on some targets, due to the
Hi Richard,
Richard Guenther <[EMAIL PROTECTED]> wrote on 05/02/2007 17:27:03:
...
>
> ...
>
> and we are later not able to do constant propagation to the
> second loop which we can do if we first unroll such small loops.
>
> As we also only vectorize innermost loops
by the way, we are working o
Richard Guenther <[EMAIL PROTECTED]> wrote on 05/02/2007 17:59:00:
> On Mon, 5 Feb 2007, Paolo Bonzini wrote:
>
> >
> > > As we also only vectorize innermost loops I believe doing a
> > > complete unrolling pass early will help in general (I pushed
> > > for this some time ago).
> > >
> > > Though
Richard Guenther <[EMAIL PROTECTED]> wrote on 05/02/2007 18:16:05:
> On Mon, 5 Feb 2007, Jan Hubicka wrote:
...
> > Did you run some benchmarks?
>
> Not yet - I'm looking at the C++ SPEC 2006 benchmarks at the moment
> and using vectorization there seems to do a lot of collateral damage
> (maybe n
Grigory Zagorodnev <[EMAIL PROTECTED]> wrote on 05/02/2007
08:18:34:
> Dorit Nuzman wrote:
> > I'm seeing this bootstrap failure on i686-pc-linux-gnu (revision
121579) -
> > something I'm doing wrong, or is anyone else seeing this?
>
> Yes. I see the same at x
I'm seeing this bootstrap failure on i686-pc-linux-gnu (revision 121579) -
something I'm doing wrong, or is anyone else seeing this?
/home/dorit/mainline/build/./gcc/gfortran
-B/home/dorit/mainline/build/./gcc/
-B/home/dorit/mainline/i686-pc-linux-gnu/bin/
-B/home/dorit/mainline/i686-pc-linux-gnu
> Even if you fix that, gcc will only vectorize if you pass the
> -ftree-vectorize option. And it will only vectorize code in loops.
Supporting straight-line code vectorization is in the works, but at first
we'll look for such opportunities only in loops (i.e. exploit
vector-parallelism within an
>
> I've reopened a new branch autovect-branch, taken off the trunk as of
> today.
> The branchpoint revision is 120362. The old branch went way out of synch
> with mainline so I've moved it to branches/dead/old-autovect-branch in
svn
> repository.
>
> New autovect-branch has initialized merge tra
>
> ((char)x) = ((char)( ((int)((char)x)) << ((int)c) ) ) ::
> ((char)x) = ((char)( ((char)x) << ((int)c) ) )
>
> if the shift count ((int)x) is semantically preserved.
>
> thereby conditionally shifting left ((char)x) by ((int)c) if c is less
than
> the smaller of it's shifted operand's or
Janis Johnson <[EMAIL PROTECTED]> wrote on 18/12/2006 20:25:47:
> On Mon, Dec 18, 2006 at 01:19:03PM +0200, Dorit Nuzman wrote:
> > Janis Johnson <[EMAIL PROTECTED]> wrote on 15/12/2006 03:12:44:
> > >
> > > I seem to recall from long ago that some p
> * Andrew Pinski:
>
> > A simple loop like:
> > int foo ()
> > {
> > int a[N];
> > int i;
> > int n;
> >
> > for (i = 0; i <= n; i++)
> > ca[i] = 2;
> > }
> >
> > we cannot find how many iterations it runs without knowing that signed
> > types overflow.
>
> In this case, the assumpti
Janis Johnson <[EMAIL PROTECTED]> wrote on 15/12/2006 03:12:44:
> Checks for vector instruction support are spreading throughout the
> testsuite. I'd like to pull the basic logic into a single place that
> can be referenced wherever it's needed. What's there now isn't always
> consistent and the
See slides 18-35 in
http://gcc.gnu.org/wiki/OptimizationCourse?action=AttachFile&do=get&target=ExampleGCC_middle.pdf
(linked from http://gcc.gnu.org/wiki/OptimizationCourse).
dorit
> Dear all,
> I wrote a new pass for gcc. Actually the pass is always executed, but
> I'd like to execute it only i
> Markus Franke wrote on 11/27/06 12:50:
>
> > Are there also some other optimisation passes working on the GIMPLE/SSA
> > representation which make use of any machine-dependent features?
> >
> Yes. Passes like vectorization and loop optimizations will use so
> called 'target hooks' which allow th
> Vladimir Yanovsky wrote:
>
> That comment was about SMS. Last time when I tried SMS for Itanium on
> SPEC2000 a few monts ago, a lot of tests did not work. As RCSP I don't
> think we need this. It is too complicated algorithm. Mainstream
> approach is modulo scheduling. I hope people from I
> On Fri, 2006-11-10 at 21:00 -0800, Alexey Starovoytov wrote:
> > while speaking about uninitialized variables gcc developers probably
want
> > to look at their own sources first:
> > gcc/testsuite/gcc.dg/vect/vect-27.c
>
> If any code in the testsuite is broken, it should be changed.
should be f
> On 11/15/06, Steven Bosscher <[EMAIL PROTECTED]> wrote:
> > On 11/15/06, Sebastian Pop <[EMAIL PROTECTED]> wrote:
> >
> > > There is a ddg in this patch if somebody wants the classic
Allen&Kennedy
> > > way to look at the dependences:
> > > http://gcc.gnu.org/wiki/OptimizationCourse?
> action=Att
Hi,
I just posted on the wiki (http://gcc.gnu.org/wiki/SwingModuloScheduling) a
list of items to improve the GCC modulo scheduler (SMS). We've been looking
into this on and off in the past year, while trying to tune it for ppc970
and then for the Cell. With relatively small tweaks, SMS is startin
>
> I see this on linux but not on cygwin:
>
> make[3]: Leaving directory `/home/dk/gnu/obj'
> Comparing stages 2 and 3
> warning: ./cc1-checksum.o differs
> warning: ./cc1plus-checksum.o differs
> warning: ./cc1obj-checksum.o differs
> Bootstrap comparison failure!
> ./cfg.o differs
> ./cfgloopa
gt; that all aligned arrays are passed as pointer-to-struct with the array
> element in the struct specified with an alignment attribute. I have
> not tested method 2; it seems like a transformation which may work
> despite being unaesthetic.
>
> Regards,
> Michael James
>
>
Unfortunately there's no way to specify alignment attribute of pointers in
GCC - the syntax was allowed in the past but not really supported
correctly, and then entirely disallowed (by this patch
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02284.html). This issue was
discussed in details in these
> I think that it is time that we in the GCC community took some time to
> address the problem of compiling very large functions in a somewhat
> systematic manner.
>
> GCC has two competing interests here: it needs to be able to provide
> state of the art optimization for modest sized functions an
"Erich Plondke" <[EMAIL PROTECTED]> wrote on 27/09/2006 18:17:55:
thanks for the detailed explanation,
> Indeed, in your paper (grin) "Multi-platform Auto-vectorization" you
>
> define the functionality of realign load in terms of mis - the
> misalignment
> of the address (i.e., a
>
> 1) The definition of the realignment instruction doesn't match hardware
for
> instrution sets like ARM WMMX, where aligned amounts shift by 0 bytes
> instead of VECSIZE byes. This makes it useless for vector realignment,
> because in the case that the pointer happens to be aligned, we get the
Hi,
> I've been tinkering with the autovectorizer. It's really cool.
> I particularly like the realignment support.
>
> I've noticed just a few things while tinkering with it (in 4.1.1):
>
thanks a lot for your comments!
>
>
> 1) The definition of the realignment instruction doesn't match hardw
opened a missed optimization PR so that I won't forget about it - PR29160
dorit
> "Devang Patel" <[EMAIL PROTECTED]> wrote on 11/09/2006 07:30:17 PM:
>
> > > Can these type casts (from uchar to schar and back) be cleaned away
> > > by some pass before vectorization, or do we need to teach the
> v
>Does anyone know if the fact that the gfortran.dg
> test case vect/vect-5.f90 is now showing a XPASS on
> indicates a regression? All three dg-final options that
> are marked to fail at lp64 now pass.
>
> Running target unix/-m64
> XPASS: gfortran.dg/vect/vect-5.f90 -O scan-tree-dump-times
"Erich Plondke" <[EMAIL PROTECTED]> wrote on 16/09/2006 05:26:50 PM:
> On 9/16/06, Dorit Nuzman <[EMAIL PROTECTED]> wrote:
> > Looks like it's a bug in the vectorizer - we treat both the return
value of
> > the mask_for_load builtin, and the 3rd
"Devang Patel" <[EMAIL PROTECTED]> wrote on 11/09/2006 07:30:17 PM:
> > Can these type casts (from uchar to schar and back) be cleaned away
> > by some pass before vectorization, or do we need to teach the
vectorizer
> > to ignore such type casts?
>
> This was considered as tree-combiner's respons
> I'm trying to add a hook for aligning vectors for loads.
>
> I'm using the altivec rs6000 code as a baseline.
>
> However, the instruction is like the iwmmxt_walign instruction in the
> ARM port; it takes
> a normalish register and uses the bottom bits... it doesn't use a
> full-width vector.
>
>
"Daniel Berlin" <[EMAIL PROTECTED]> wrote on 11/09/2006 06:27:16 PM:
> On 9/11/06, Dorit Nuzman <[EMAIL PROTECTED]> wrote:
> > >A silly little testcase which the vectorizer doesn't vectorize:
> > >
> >
> > > autovecttest.c
>A silly little testcase which the vectorizer doesn't vectorize:
>
> autovecttest.c:11: note: not vectorized: relevant stmt not
> supported: D.1861_9 = (signed char) D.1860_8
Can these type casts (from uchar to schar and back) be cleaned away by some
pass before vectorization, or do we ne
I think this patch by Zdenek - vectorizing function calls - is related:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01655.html
(would need to be extended to cover this case).
dorit
> On 7/28/06, François-Xavier Coudert <[EMAIL PROTECTED]> wrote:
> > I've been doing some benchmarking of gfortran
Steven Bosscher <[EMAIL PROTECTED]> wrote on 29/07/2006 12:46:34 PM:
> Hi,
>
> I was browsing DannyB's patch queue, and saw that there are many
> patches for the vectorizer that have apparently not been reviewed:
>
...
>
> Dorit, why haven't you pinged any of these patches?
>
I was away for a fe
Martin Michlmayr <[EMAIL PROTECTED]> wrote on 29/07/2006 01:16:03 PM:
> * Steven Bosscher <[EMAIL PROTECTED]> [2006-07-29 11:46]:
> > Some of these patches are bug fixes but others are listed GCC 4.2
> > projects, so can/should they still go into GCC 4.2?
>
> There was some discussion about this a
Paolo Bonzini <[EMAIL PROTECTED]> wrote on 16/01/2006 18:56:52:
> Dorit Nuzman wrote:
>
> >>I am pretty sure that adding -fwrapv will
> >>fix the problem, but that means we are changing the test case.
> >>
> >>
> >
> >gen-vect-11.c is
> I am pretty sure that adding -fwrapv will
> fix the problem, but that means we are changing the test case.
gen-vect-11.c is Paolo's test, so it's his call I guess
(he already agreed to add -fwrapv -
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00579.html)
dorit
Eric Botcazou <[EMAIL PROTECTED]
95 matches
Mail list logo
