Hi JC,
On Thu, Mar 12, 2009 at 10:58, fearyourself wrote:
> Dear all,
>
> I've been trying to add a pass that adds a function call at the
> beginning of each function. However, my first solution was to simply
> do something like this:
>
> bb = ENTRY_BLOCK_PTR ->next_bb;
> i = bsi_start (bb);
> tr
appears this file
> uses this header, not available on MinGW, unconditionally with no
> configure checks.
>
I committed the attached fix to the cloog-ppl repo, and I will prepare
a new tar.gz for the gcc infrastructure.
Sebastian Pop
--
AMD - GNU Tools
diff --git a/configure.in b/configu
On Tue, Mar 31, 2009 at 21:41, Ryan Hill wrote:
> On Sun, 29 Mar 2009 14:11:37 -0500
> Sebastian Pop wrote:
>
>> I committed the attached fix to the cloog-ppl repo, and I will prepare
>> a new tar.gz for the gcc infrastructure.
>
> Is changing the contents of the t
t; libraries.
>
What would we have to do to make PPL and CLooG required to build GCC?
Sebastian Pop
--
AMD - GNU Tools
On Fri, Apr 24, 2009 at 08:12, Robert Dewar wrote:
>> What would we have to do to make PPL and CLooG required to build GCC?
>
> Why would that be desirable? Seems to me the current situation is
> clearly preferable.
To enable loop transforms in -O3.
Sebastian Pop
--
AMD - GNU Tools
On Wed, Apr 29, 2009 at 16:57, Richard Guenther
wrote:
>>
>> * Reductions: Diego OK with going out of SSA.
>
> You will loose all points-to information. I think going out of SSA is
> a very bad idea.
>
There is no loss of information: we go out of SSA only for scalar phi
nodes that cannot b
On Wed, Apr 29, 2009 at 17:15, Richard Guenther
wrote:
> I don't see how SSA form makes anything more complicated ;)
>
One of the difficulties was regenerating the phi nodes after code
hoisting: CLooG optimizes
for (i)
if (invariant of i)
s += A[i];
into
if (invariant of i)
for (i)
On Mon, May 11, 2009 at 14:18, Ian Lance Taylor wrote:
> I'm having some trouble building the Graphite support.
>
> Using ftp://gcc.gnu.org/pub/gcc/infrastructure/ppl-0.10.2.tar.gz :
>
> * Unlike gcc, does not support a --with-gmp option.
> + Does support a --with-libgmpxx-prefix option.
> * If G
On Sat, Jun 27, 2009 at 11:51, David Edelsohn wrote:
> 2) The Graphite CLooG headers are not C++-clean, so enabling Graphite
> fails in CXX mode.
I did applied the patches from Ian to the cloog-ppl git.
The git version should compile with a C++ compiler.
Sebastian
Hi,
On Mon, May 17, 2010 at 15:15, Sandeep Soni wrote:
> Hi,
>
> As part of GSoC 2010, I am developing a front end for GIMPLE.
> You can find the basic theme of the project at:
> http://gcc.gnu.org/wiki/GimpleFrontEnd
>
> One of the most important components in this GIMPLE Front End is to
> conve
higher level insns?
Thanks,
Sebastian Pop
--
AMD / Open Source Compiler Engineering / GNU Tools
On Mon, Jun 21, 2010 at 17:21, Jeff Law wrote:
> Ouch. You've got another problem in that combine doesn't combine across
> basic blocks.
Actually tree-if-conversion does take care of transforming the inner loop
into one BB to enable vectorization. So we don't have the cross-BB
combine problem.
http://gcc.gnu.org/PR43359: gas_dyn benchmark exhibits missed
vectorization with graphite
Sebastian Pop
--
AMD / Open Source Compiler Engineering / GNU Tools
On Tue, Jul 27, 2010 at 21:09, Jack Howarth wrote:
> When do you think we may start to see the vectorizations in
> Gr1 exceed those from Gr0?
I know at least of one case http://gcc.gnu.org/PR43423 that is still
not vectorized and that would benefit of the -fgraphite-identity (that
does iterati
Toon,
>From your backtrace it looks like a problem in LNO.
Please submit a bug report and attach your testcase.
Thanks,
Sebastian
On Thu, Aug 5, 2010 at 15:00, H.J. Lu wrote:
> I saw
> ==23110== by 0xAA5809: tree_loop_distribution
> (tree-loop-distribution.c:1199)
Mine.
Thanks for running the trace,
Sebastian
I'm delta reducing this.
Toon, have you opened a bug, or do you want me to open the bug report?
Thanks,
Sebastian
On Thu, Aug 5, 2010 at 15:07, Sebastian Pop wrote:
> I'm delta reducing this.
Reduced it looks like this, and it seems like the bug is in the loop
distribution
for memset zero changes.
parameter(numlev=3,numoblev=1000)
integer i_otyp(numoblev,numlev), i_styp(numoble
On Thu, Aug 5, 2010 at 15:17, Sebastian Pop wrote:
> On Thu, Aug 5, 2010 at 15:07, Sebastian Pop wrote:
>> I'm delta reducing this.
>
> Reduced it looks like this, and it seems like the bug is in the loop
> distribution
> for memset zero changes.
>
>
On Wed, Aug 11, 2010 at 10:29, Jie Zhang wrote:
> Hi Sebastian,
>
> I currently encountered an issue when testing
> gcc.dg/graphite/interchange-9.c on a ARM bare-metal board which has only 4MB
> memory.
>
> Apparently, with
>
> #define N
> #define M
>
> "int A[N*M]" in main is too large
On Tue, Sep 14, 2010 at 10:19, Paulo J. Matos wrote:
> How can I automatically update dominators? Or do I have to do it for
> each new basic_block I create with recompute_dominator?
/* Free and compute again all the dominators information. */
static inline void
recompute_all_dominators (void)
{
On Tue, Sep 14, 2010 at 10:52, Paulo J. Matos wrote:
> mark_irreducible_loops is actually failing with a segmentation fault:
It looks like you don't work at a level where the loops are built.
So don't call mark_irreducible_loops, just use what Richi suggested:
free_dominance_info (CDI_DOMINATORS
Hi,
I would like to ask the opinion of C/C++ maintainers about the extension
that the Intel compiler proposes for array notations:
http://software.intel.com/sites/products/documentation/studio/composer/en-us/2011/compiler_c/index.htm#optaps/common/optaps_par_cean_prog.htm
Are there strong opinion
On Mon, Dec 13, 2010 at 11:14, Xinliang David Li wrote:
> Any comment on the following?
>
> http://blog.regehr.org/archives/320
>
> 1) is due to lack of non-linear induction variable support
> 5) is the same problem mentioned in pr35363
>
Example 2) is now http://gcc.gnu.org/PR46928
Sebastian
On Tue, Jan 4, 2011 at 10:22, Richard Guenther
wrote:
> Ugh. Sebastian - can we nuke tree-loop-linear compeltely and
> make -ftree-loop-linear an alias for -floop-interchange without
> regressions? I'd like to reduce the number of broken passes from
> 2 to 1 this way ...
I wouldn't mind removin
On Wed, Jan 5, 2011 at 08:23, Jack Howarth wrote:
> On Sun, Jan 02, 2011 at 04:55:09PM +0100, Richard Guenther wrote:
>> On Fri, Dec 31, 2...@12:40 AM, Jack Howarth wrote:
>> > Sebastian,
>> > It appears that the official tarballs are now
>> > pos...@http://www.cloog.org/
>> > for cloog and c
Jeffrey A Law wrote:
>
> Note how the conversions have been lost.
>
This is a bug in chrec_convert_aggressive.
The following patch fixes the problem in a quite drastic way,
disabling the analysis of ivs that contain casts in their induction.
Index: tree-scalar-evolution.c
=
Richard Kenner wrote:
> Just to make sure I've dotted the i's and crossed the t's, this is not
> what's happening when we hang in VRP when compiling a-textio.
>
> We convert the incoming object from natural___XDLU_0___2147483647
> into its base type, perform the addition in the bas
Jeffrey A Law wrote:
> One possibility that isn't as drastic would be to add one to the
> TYPE_MAX_VALUE of the inner type, then see if the result fits in
> the outer type.
Yes, that's basically the idea that is implemented in chrec_convert.
Because we're in a loop and we keep adding "one"s to
Jeffrey A Law wrote:
> Another possibility is to simply not allow conversions between a
> subtype and basetype.
Such a patch also solves the problem. But I'm not sure to understand
the impact on other codes. Is this kind of conversion between a type
and its basetype specific to Ada?
Index: tre
Jeffrey A Law wrote:
> I suspect, but certainly have not confirmed that these conversions
> are very common in Ada, but relatively rare elsewhere. Confirming
> that suspicion one way or the other is on my TODO list for the weekend.
>
okay, thanks for your investigation. I won't be able to read
Jeffrey A Law wrote:
> On Fri, 2006-02-24 at 19:47 +0100, Sebastian Pop wrote:
> > Jeffrey A Law wrote:
> > > Another possibility is to simply not allow conversions between a
> > > subtype and basetype.
> >
> > Such a patch also solves the problem. But I&
Jeffrey A Law wrote:
> I wouldn't have a problem with non-canonical bounds if there were
> no way to get a value into an object which is outside the
> bounds. But if we can get values into the object which are outside
> those bounds, then either the bounds are incorrect or the program
> is invali
Daniel Berlin wrote:
> Thus, it is algorithmically unsound in it's current form :)
> Again, this is *only* the piece that attempts to convert loops
> to perfect nests.
> This is in fact, not terribly surprising, since the algorithm used was the
> result of
> Sebastian and I sitting at my whiteboa
Diego Novillo wrote:
> Richard Henderson wrote on 06/08/06 16:36:
>
> > As folks have pointed out down-thread wrt multi-dimensional arrays,
> > I think this is a rather poor idea. Both for components and arrays.
> >
> Yeah, multi-dimensional arrays are a problem. I'm not sure I see the
> flatte
ot the
> initial source code level, of course ;-)) - RTL, GIMPLE, GENERIC?
Any.
> 3. Are there any attempts to provide a C backend, so far?
>
Yes, gcc2c from sun.com, though this is a dead project for more than 3
years now.
Sebastian Pop
Steven Bosscher wrote:
> 2. Probably GIMPLE, but you can't express all of GIMPLE in ANSI C
> (with GCC extensions you can probably express most of it though).
Theoretically you can express all of GIMPLE in ANSI C,
practically it would require some engineering,
pragmatically it is worthless for GCC
Diego Novillo wrote:
> Roberto COSTA wrote on 06/12/06 03:50:
>
> > Every so often CIL looks to poke in the works of the mailing list, but I
> > haven't been able to track the current status of the discussion on the
> > topic.
> >
> We have started work on a bytecode representation that will initi
Diego Novillo wrote:
> > The document in which Mark has announced the LTO briefly mentions
> > that CIL was not retained for dumping the IR, without giving an
> > explicit reason, so I think that we need a clear position from the
> > FSF whether such a backend is accepted to be part of GCC.
> >
Roberto COSTA wrote:
> Ori Bernstein wrote:
> >On Mon, 12 Jun 2006 09:50:13 +0200, Roberto COSTA <[EMAIL PROTECTED]>
> >said:
> >
> >
> >>Hello,
> >>
> >>I'm working for an R&D organization of STMicroelectronics. Within our
> >>team we have decided to write a gcc back-end that produces CIL binar
kernel coder wrote:
> is there any way in gdb to step backward.
>
not yet, and if this feature is implemented it should be quite
restricted, think about undoing side effects, as disk read/write...
But you can put a breakpoint before the current point, and then run
again gdb on your program.
Daniel Jacobowitz wrote:
> It doesn't have an actual reverse debugging implementation yet - but
> it's been proposed.
>
Here it is, but I don't know the exact current status of the proposal:
http://sourceware.org/ml/gdb/2006-01/msg00013.html
Here is the documentation for the data dependence analysis.
@node Dependency analysis
@section Data Dependency Analysis
@cindex Data Dependency Analysis
The code for the data dependence analysis can be found in
@file{tree-data-ref.c} and its interface and data structures are
described in @file{t
Joe Buck wrote:
> On Wed, Aug 30, 2006 at 06:52:59PM +0200, Basile STARYNKEVITCH wrote:
> > Le Wed, Aug 30, 2006 at 06:36:19PM +0200, basile écrivait/wrote:
> > >
> > > Maybe some of your are aware of MyGCC http://mygcc.free.fr/ which
> > > seems to be an extended GCC to add some kind of static an
Sebastian Pop wrote:
> In my opinion the patch needs major rework and improvements to be
> included in trunk.
Here is my short review of the mygcc patch that lists some possible
improvements and things that have to be redesigned:
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00616.html
Daniel Berlin wrote:
> >As some few people might already know, the GGCC (globalgcc) project is
> >just starting (partly funded within the ITEA framework by french,
> >spanish, swedish public money) - its kick off meeting is next week in
> >Paris.
> >
> >GGCC aims to provide a (GPL opensource) exten
Ira Rosen wrote:
>
> > Here is the documentation for the data dependence analysis.
>
> I can add a description of data-refs creation/analysis if it is useful.
>
That's a good idea, thanks.
Sebastian
Thank you, the documentation looks good.
Ira Rosen wrote:
>
> @item @code{first_location_in_loop}: Provides information about the first
> location accessed by the data reference in the loop and about the access
> function used to represent evolution relative to this location. This data
> is used
Basile STARYNKEVITCH wrote:
>
> How does one get the source location (e.g. start and end filename,
> linenumber, ...) of a tree node;
You can use the same code as in tree-vectorizer.h:
#ifdef USE_MAPPED_LOCATION
typedef source_location LOC;
#define UNKNOWN_LOC UNKNOWN_LOCATION
#define EXP
e a matrix multiplication loop
To: s...@gcc.gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14741
--- Comment #18 from Sebastian Pop ---
On my laptop ARM Exynos5 at 1.6GHz I get this:
gfortran -ffast-math -O3 t.f90
./a.out
192.7510.2399826
gfortran -ffast-math -O3
:24 AM, Sebastian Pop wrote:
>>
>> Hi Jeff,
>>
>> let's start with getting this bug fixed.
>
> So what do you need? Just making the tiling factor won't solve the problem
> AFAICT. As I've mentioned, I'm already over-booked on other things and
&g
, Sebastian Pop wrote:
> For this testcase, it looks like the scop detection pass should be fixed:
> it currently discards the interesting loop nest. I can help figuring out what
> is needed to be fixed, though I cannot send patches to fix the problem.
>
> On Thu, Jul 18, 2013 at 11:
Hi,
one more leak, this time in alias analysis that initializes an obstak
without freeing it. This is with the testcase of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23821
valgrind --leak-check=full cc1 -O2 pr23821.c
==16661== 9,244 bytes in 68 blocks are definitely lost in loss record 2 of 5
Hi,
When a loop is vectorized, some statements are removed from the basic
blocks, but the vectorizer information attached to these BBs is never
freed. This is because the attached information is freed by walking
the statements of the basic blocks: see tree-vectorizer.c:1750, but
the transformed c
On Feb 6, 2008 9:02 PM, Richard Kenner <[EMAIL PROTECTED]> wrote:
> Which would be more interesting: a tutorial on the Ada language itself or
> on the "demands" it places on GCC?
I would say that both tutorials sound interesting ;-)
When I first heard a tutorial on the Ada language, I found it ve
2008/2/7 Tobias Grosser <[EMAIL PROTECTED]>:
> 2. Which loops are part of a SCoP:
>
> At the moment we detect the loops, which are part of a SCoP like this:
>
> FORALL_BB_IN_SCOP(bb)
> {
> VEC_loops_add(bb->loop_father);
> }
>
> This seems incorrect if we look at this SCoP:
>
> h #loop0
> |
> a
On Mon, Mar 3, 2008 at 3:08 PM, Richard Guenther <[EMAIL PROTECTED]> wrote:
> I am aware of the following merge candidates: the LTO branch, the
> incremental compiler branch, the selective scheduling branch, the
> YARA branch and of course the tuples branch. Please announce those
> I forgot so
On Wed, Apr 16, 2008 at 10:44 AM, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> Huh??? Spu support is in gcc 4.3.0.
>
Ok, GCC4.3 can compile for Cell, but what is the status of libGOMP on
Cell? Is there an efficient port of libGOMP for Cell? I assume that
the linux port could be used for Cell, bu
On Thu, Apr 17, 2008 at 10:36 PM, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> Correct. I was just trying to correct the idea that spu support was
> not committed to the FSF GCC. Considering I am a maintainer of it
> too, I don't want people to get the wrong thought there.
>
Ok, I got an email
On Fri, Apr 18, 2008 at 3:32 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> 3- Delay the end of stage 1 till mid June or so. I don't see the need to
> rush out with 4.4 release, when it would have only limited advantages over
> 4.3 to offer. Having IRA, Tuples, OpenMP3 (what other branches mig
On Fri, May 9, 2008 at 2:09 AM, Sandeep Maram <[EMAIL PROTECTED]> wrote:
> i_23 is the loop iterator of loop_2 . i_22 is the loop iterator of loop_1.
>
> How can I rename i_23 as i_22?
>
In lambda-code.c:1858 you have some code that does a similar renaming:
FOR_EACH_IMM_USE_STMT (stmt, imm_iter,
Hi,
> So the statement
> j_12 = D.1190_11 + j_24;
> is now present in loop_b, but I am unable to create the phi node for
> it in loop_b. I tried to do so using
> for (phi = phi_nodes (loop_a->header);
> phi;)
>{
> next = PHI_CHAIN (phi);
> create_phi_node (SSA_NAME_VAR (PHI_RES
AMD Opteron 8354 "Barcelona B3" processors
and 16GB of RAM to the GCC Compile Farm
project for use by free software developers. Hosting is donated
by http://www.inria.fr/saclay/";>INRIA Saclay.
Thanks,
Sebastian Pop
--
AMD - GNU Tools
On Fri, May 23, 2008 at 8:03 PM, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
> On Fri, 23 May 2008, Sebastian Pop wrote:
>> AMD Developer Central has generously donated two bi-quad core
>> machines with the latest AMD Opteron 8354 "Barcelona B3" processors
>> an
ops.
>
This was also the case before: we needed a map between the old
induction variable and the new ones.
Sebastian Pop
--
AMD - GNU Tools
pe not years).
Sebastian Pop
--
AMD - GNU Tools
Hi Tobias,
On Wed, Aug 20, 2008 at 4:45 PM, Tobias Grosser
<[EMAIL PROTECTED]> wrote:
> So even if Google Summer of Code has finished. I do not want to say
> "Goodbye", but "Hello" to you.
> I am looking forward to work with you on gcc and graphite!
>
I would like to say a big thank you for your
On Tue, Sep 2, 2008 at 6:00 AM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> The trunk is now in stage3 phase, so only bugfixes, documentation changes
> and new ports are allowed at this point. As an exception the GRAPHITE
> branch, which has been AFAIK mostly approved already but missed the deadlin
On Tue, Sep 2, 2008 at 8:42 PM, Tobias Grosser
<[EMAIL PROTECTED]> wrote:
> It seems this code is already there, but the check for
> "check_effective_target_fgraphite" fails. I attached a patch. Now the
> graphite test cases are only executed, if graphite is available.
>
The patch looks good: the
On Wed, Sep 3, 2008 at 1:19 PM, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> Maybe it is better to error out if -fgraphite is used even without
> optimization if the compiler does not have the required libraries.
>
Patch attached.
Sebastian
* toplev.c (process_options): Fail and warn when graphit
On Wed, Sep 3, 2008 at 1:24 PM, Steve Kargl
<[EMAIL PROTECTED]> wrote:
> I think that this is sensible considering that cloog is only
> available through a git repository. Requiring people to install
> git to build cloog is somewhat un-user-friendly.
I will prepare a cloog.tar.gz and will put it
ROW'09 EasyChair online submission website:
http://www.easychair.org/conferences/?conf=grow09
Organizers:
Paul H.J. Kelly, Imperial College of London, UK
Sebastian Pop, AMD, USA
Program Committee:
Albert Cohen, INRIA, France
Grigori Fursin, INRIA, France
Benedict Gaster, AMD, US
meeting will be hosted on the AMD campus in
Austin. The workshop is organized before the SuperComputing'08
conference in November, and it is not affiliated with this conference.
Sebastian Pop
--
AMD - GNU Tools
Hi,
Antoine Eiche <[EMAIL PROTECTED]> wrote:
Why can I not do "foo(a + i * x)" then I can do "foo(i * x)" ou "foo(a + i)" ?*
[...]
When a try to compile a program gcc answer:
"
tab.c:22: erreur: invalid operand to binary operator
i_28 * 4;
tab.c:22: erreur interne du compilateur: verify_stm
On 6/13/07, Revital1 Eres <[EMAIL PROTECTED]> wrote:
Hello,
I have two ssa vars (i0 and i1 in the following example); what is the
sequence to generate a new phi node corresponding to i3 -
if (...)
i0 = exp1
else
i1 = exp2
i3 = PHI(i0 , i1);
From tree-vectorizer.c,
/* 1.1
On 6/18/07, Dorit Nuzman <[EMAIL PROTECTED]> wrote:
> 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
Interesting. I wasn't aware of this potential. Please do send some of this
code. thanks!
I'm thinking about
On 9/4/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> We are closing in on Stage 3, previously announced for September 10th.
> At this point, I'm not aware of any reason to delay that date. Are
> there any Stage 2 patches that people don't think will be submitted by
> that point?
>
I still plan t
On 10/24/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
> We are also thinking about lowering GIMPLE a bit further and delay
> the transition into RTL.
Diego, can you be more specific about what parts you think have to be
lowered more from GIMPLE?
Together with Richard Guenther, we're planing to se
On Oct 29, 2007 10:49 AM, Dorit Nuzman <[EMAIL PROTECTED]> wrote:
> I wonder if it's versioning-for-aliasing (run-time dependence testing) that
> was responsible for a lot of the new vectorizable loops
>
It is then possible that the code size noticeably increased. Toon
could you provide more data
Hi,
In a recent update of the page http://gcc.gnu.org/wiki/Graphite I left
the "Testing Lambda and Graphite frameworks" part in the open tasks.
One of the subitems of this task is:
"Add expect scripts for comparing outputs of testcases compiled with
different options. For instance compare output
On Nov 28, 2007 6:36 PM, Janis Johnson <[EMAIL PROTECTED]> wrote:
>
> On Wed, 2007-11-28 at 15:00 -0600, Sebastian Pop wrote:
> > Hi,
> >
> > In a recent update of the page http://gcc.gnu.org/wiki/Graphite I left
> > the "Testing Lambda and Graphite frame
On Dec 7, 2007 8:28 AM, Emmanuel Fleury <[EMAIL PROTECTED]> wrote:
> Is anyone planning to go at CC'08 or COCV'08 ?
I was planning, but my paper at ESOP'08 was rejected, so I won't go there ;-)
Sebastian
Please stop spamming my gcc@gcc.gnu.org email box.
All the messages that you sent are just off-topic for this mailing list.
Please STOP sending emails.
Thank you,
Sebastian Pop
On Dec 12, 2007 4:42 PM, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
>
> On 2007/12/12, Jonathan Wakely <[
Hi,
I've run a build for spec cpu2006 with -O3 -ftree-parallelize-loops=16
and interestingly there were some fails that I will investigate later.
So I'm just reporting these, and asking for somebody who could fix
the link options for autopar. I'm attaching a patch, not sure it will build.
Before
> I've run a build for spec cpu2006 with -O3 -ftree-parallelize-loops=16
This is on amd64-linux.
le without -ftree-loop-linear
>
Could you verify that the attached patch fixes also this problem?
Thanks again,
Sebastian
2007-12-15 Sebastian Pop <[EMAIL PROTECTED]>
* lambda-code.c (can_duplicate_iv): New.
(cannot_convert_modify_to_perfect_nest): New.
(cannot_convert_bb_to_perfect_
On Dec 16, 2007 4:24 AM, Toon Moene <[EMAIL PROTECTED]> wrote:
> Here are, in addition, the numbers for compiling and
> running HIRLAM with -ftree-loop-distribution (after applying your patch,
> obviously).
>
> In short, almost 1900 more loops are vectorized, but that's of course
>
101 - 187 of 187 matches
Mail list logo
