On Fri, Oct 12, 2018 at 2:14 PM Marc Glisse wrote:
> On Fri, 12 Oct 2018, Thomas Schwinge wrote:
>
> > Hmm, and without any OpenACC/OpenMP etc., actually the same problem is
> > also present when running the following code through the vectorizer:
> >
> >for (int tmp = 0; tmp < N_J * N_I; ++tm
On Fri, Nov 20, 2015 at 10:43 AM, David Edelsohn wrote:
> On Fri, Nov 20, 2015 at 11:28 AM, Sebastian Pop wrote:
>> Thanks David for reporting these problems.
>>
>> On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn wrote:
>>> (2) All of the graphite*.c files in
On Fri, Nov 20, 2015 at 10:23 AM, Sven Verdoolaege wrote:
> On Fri, Nov 20, 2015 at 10:14:47AM -0600, Sebastian Pop wrote:
>> On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn wrote:
>> > Sebastian,
>> >
>> > I have tried to build GCC with Graphite and ISL on A
Thanks David for reporting these problems.
On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn wrote:
> (2) All of the graphite*.c files include ISL headers first. This
> order is not supported by GCC development and creates conflicts for
> types and definitions provided / overridden by GCC headers,
On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn wrote:
> Sebastian,
>
> I have tried to build GCC with Graphite and ISL on AIX and encountered
> two problems:
>
> (1) isl/ctx.h
>
> typedef enum {
> isl_stat_error = -1,
> isl_stat_ok = 0,
> } isl_stat;
>
> GCC complains about the co
Segher Boessenkool wrote:
> On Tue, Sep 08, 2015 at 06:39:19PM +, Aditya K wrote:
> > IIUC, in the haifa-sched.c, the default scheduling algorithm seems to be
> > top-down (before reload).
> > Is there a way to schedule the other way (bottom up), or both ways?
> >
> > As a use case for bottom
15 at 3:53 PM, Dehao Chen wrote:
> That's correct. For trunk, gcov_version is 0x1. We defined this as a
> flag so that you can actually change it via --gcov_version=0x1 instead
> of changing the code.
>
> Dehao
>
> On Tue, Apr 21, 2015 at 1:47 PM, Sebastian Pop wr
We also needed to adjust the gcov_version in autofdo/gcov.cc to read
0x1 for dev branches of gcc (instead of the current 0x3430372a for
some released version of GCC):
-DEFINE_uint64(gcov_version, 0x3430372a,
+DEFINE_uint64(gcov_version, 0x1,
Sebastian
On Tue, Apr 21, 2015 at 3:33 PM, Aditya K w
On Tue, Apr 7, 2015 at 3:33 AM, Richard Biener
wrote:
>> Having an IR that is more readable than LLVM's would be nice.
>
> I still like the idea of using C + extensions most.
+1
> As well as making the
> -fdump-tree-XXX dumps (more) valid C (+ extensions). Cut & pasting
> from dump files to gen
On Fri, Apr 3, 2015 at 1:10 PM, Jeff Law wrote:
> On 04/03/2015 09:41 AM, Diego Novillo wrote:
>>
>> On Fri, Apr 3, 2015 at 11:35 AM, Jeff Law wrote:
>> I was hesitant to offer this option, but it's certainly a good
>> starting point. The representation encodes CFG, SSA, attributes,
>> declarati
Hi,
my colleague Brian has posted the instructions to set up
an AArch64 virtual machine running ubuntu on top of qemu:
http://rzycki.blogspot.com/2014/08/using-qemu-to-run-ubuntu-arm-64-bit.html
We are using this setup to bootstrap gcc on aarch64.
Sebastian
, 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:
: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
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
On Fri, Aug 12, 2011 at 12:50, Jack Howarth wrote:
> On Fri, Aug 12, 2011 at 07:35:24PM +0200, Sven Verdoolaege wrote:
>> On Fri, Aug 12, 2011 at 05:02:18PM +, Joseph S. Myers wrote:
>> > On Fri, 12 Aug 2011, Sebastian Pop wrote:
>> > > +@item Integer
Hi,
I put the scripts that we are using to test performance regressions of GCC on
git://repo.or.cz/gcc-perf-regression-tester.git and I've wrote a small
intro page
http://gcc.gnu.org/wiki/PerfRegressionTester in the hope that these scripts will
be useful to other people.
I've been thinking to ins
On Thu, May 26, 2011 at 09:58, Alexey Kravets wrote:
> On 05/24/2011 10:09 PM, Sebastian Pop wrote:
>>
>> One change that I introduced sometime in February is that some reductions
>> are not translated to a zero dim array to make the dependence test work
>> on some o
On Tue, May 24, 2011 at 09:09, Alexey Kravets wrote:
> There are two places in graphite-opencl where we use strcmp technique.
> The first one is the detection of privatizable variables
> (opencl_private_var_name_p) and it can be eliminated by marking all zero
> dimensional arrays as private (see p
On Fri, May 20, 2011 at 08:27, Basile Starynkevitch
wrote:
>> What is your definition of induction variable?
>
> The one which is used by graphite.
Ok, then you can match against the scalar evolution of a variable:
the evolution of your variable should be of the form "{a, +, 1}_x"
with "x" the nu
On Thu, May 19, 2011 at 09:21, Basile Starynkevitch
wrote:
> I am coding a pass in MELT which should ideally transform some OpenCL things
> into Gimple
I think you mean Gimple to OpenCL.
> (yes, I do know that this has been done by Andrey Belevantset et
> al in their http://www.gccsummit.org/201
On Wed, Feb 9, 2011 at 00:20, Tony Poppleton wrote:
>> While I appreciate Phoronix as a booster site, their benchmarking
>> practice often seems very dodgy; I'd take the results with a large grain
>> of salt
>
> The main reason I posted the link in the first place was because it
> was reflecti
On Tue, Feb 8, 2011 at 16:14, Xinliang David Li wrote:
> What are the base option set used in all the comparison? O2, O3? Some
The flags are those set by the Makefiles of the different benchmarks
(as downloaded from the web).
Setting different flags with CFLAGS=... is painful.
> of the build t
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
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 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
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 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
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 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 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 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
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: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
Toon,
>From your backtrace it looks like a problem in LNO.
Please submit a bug report and attach your testcase.
Thanks,
Sebastian
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
http://gcc.gnu.org/PR43359: gas_dyn benchmark exhibits missed
vectorization with graphite
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.
higher level insns?
Thanks,
Sebastian Pop
--
AMD / Open Source Compiler Engineering / GNU Tools
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
On Tue, Apr 13, 2010 at 14:42, Jakub Jelinek wrote:
> if (!is_gimple_reg (var))
>
> you shouldn't create SSA name and change the lhs of the stmt.
>
This worked well. Thanks Jakub!
Sebastian
On Tue, Apr 13, 2010 at 13:14, Sebastian Pop wrote:
> Hi,
>
> While working on the tree-if-conv.c, I realized that the copy
> of the contents of a non scalar variable are not correctly done.
> The copy assignment triggers this error:
>
> error: virtual SSA name for non-VOP d
Hi,
While working on the tree-if-conv.c, I realized that the copy
of the contents of a non scalar variable are not correctly done.
The copy assignment triggers this error:
error: virtual SSA name for non-VOP decl
while verifying SSA_NAME _ifc_.2005_46 in statement
# .MEM_394 = VDEF <.MEM_475>
on was whether options like --with-cloog should cause configure
> to exit as failed when they can't be satisfied rather than proceeding?
> Does a failure to meet the required gmp/mpfr/mpc version requirements
> behave the same way or do they abort the configure process?
>
On Tue, Feb 9, 2010 at 12:34, Cristianno Martins
wrote:
> Hi,
>
> Thanks for the fast reply. Only one more thing: is there some way that
> I could force it to be signed??
I guess that you should wait the fixes from Tobias and Ramakrishna to
CLooG and Graphite to have the type of the IV exposed by
On Wed, Jan 13, 2010 at 14:55, Rainer Emrich wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> IMHO it would be a godd idea to add the following two configure options to ppl
> configure:
> --with-gmp-include=DIR GMP include directory
> --with-gmp-lib=DIR GMP lib directory
>
> On
On Fri, Dec 4, 2009 at 11:08, Cédric Bastoul wrote:
> We usually call this case (parameter times IV) "fully parametric".
> Armin Grosslinger looked at it before finding a more general solution,
I don't want the more general solution: IV * IV doesn't commonly
happen, but parameter * IV does, and o
On Fri, Dec 4, 2009 at 10:44, Cédric Bastoul wrote:
> I see no way to do this with affine scattering. We would need
> polynomial functions like Armin Grosslinger is doing, see
> http://www.infosun.fim.uni-passau.de/cl/publications/docs/MIP-0803.pdf
> but I think that's too slow at the moment...
I
On Fri, Dec 4, 2009 at 10:39, Tobias Grosser wrote:
> I do not believe this is already possible for arbitrary N.
>
> You would have to write a scattering function like this
>
> s0 = i+n*(j-1)
>
> What is
>
> s= i + n*j - n
> ^^^ Here is a product that is not affine linear.
Yes this is affi
On Fri, Dec 4, 2009 at 09:41, Toon Moene wrote:
> I wonder if Graphite can do this one (or is planned to be able to):
>
> Another loop optimization that suggests itself
> is the following, trying to eliminate unnecessary
> loop constructs:
> \begin{verbatim}
> SUBROUTINE SUB(A, B, C, N, M)
>
Hi Toon,
On Mon, Nov 30, 2009 at 13:51, Toon Moene wrote:
> Sebastian,
>
> I saw you updated the Graphite Wiki page, and I wondered if there are any
> concrete plans on loop fusion.
>
> The reason I ask is because in Fortran (as of Fortran 90) one often sees
> assignments like:
>
> REAL, ALLOCATA
Hi Ian,
On Tue, Nov 10, 2009 at 17:21, Ian Lance Taylor wrote:
> For the last year and a half I've been working on a gcc frontend for
> Go, a new experimental systems programming language designed by a
> small group at Google. We've just open sourced it. You can read more
> about it at http://g
Hi,
> Seems that use info is not updated.
>
You should put a TODO_update_ssa in the flags of prefetching pass.
With the attached patch I don't see an error.
Also, why don't you use trunk for your developments?
Sebastian
diff --git a/gcc/tree-flow.h b/gcc/tree-flow.h
index 1d2e69a..1320b5a 10064
Hi,
On Thu, Aug 13, 2009 at 04:02, Eric Fisher wrote:
> The error is reported in build2_stat, by
>
> gcc_assert (POINTER_TYPE_P (tt) && POINTER_TYPE_P (TREE_TYPE (arg0))
> && INTEGRAL_TYPE_P (TREE_TYPE (arg1))
> && useless_type_conversion_p (sizetype, TREE_TYPE (arg1)
On Mon, Aug 10, 2009 at 04:22, Rainer Emrich wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> I build my gcc windows versions (*-pc-cygwin, *-pc-mingw32, *-w64-mingw32)
> using
> static build libraries gmp, mpfr, mpc, ppl and cloog. Configuration and
> building
> of gcc is really easy
Hi,
On Thu, Jul 23, 2009 at 10:55, Jack Howarth wrote:
> Is it known yet whether the changes in cloog/ppl will require
> new soversions of those libraries or might the new cloog/ppl
> libraries be backward compatible with current gcc 4.4.x (ie have
> the same soversion number but a higher compati
On Thu, Jul 16, 2009 at 10:45, Daniel Berlin wrote:
> So if i understand you right, it seems all you've done is inverted the
> existing alias/points-to sets.
> IE instead of saying A has B, C, D in it's alias set, you are saying B
> is in the alias set of A, C is in the alias set of A, D is in the
On Tue, Jul 14, 2009 at 11:03, Sebastian Pop wrote:
>> Why do you need alias-set numbers?
>
> We want to represent the alias set information as an extra subscript
> on memory accesses: for example,
>
> if we have A[10] and supposing that A is in alias set 6, this woul
On Tue, Jul 14, 2009 at 10:26, Richard
Guenther wrote:
> What do you mean by 'different number for each alias set'?
An alias set numbering maps alias sets to integer numbers,
and that map is one-to-one.
> If you want to have a number that is the same for all conflicting
> memory references then
Hi Richi,
On Tue, Jul 14, 2009 at 04:40, Richard
Guenther wrote:
> You misunderstood what alias-set numbers represent. Alias-set
> numbers encode type-based alias information only - which in
> your case cannot disambiguate a or Q.
>
I also have misunderstood this.
> For dependency checking you
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
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 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 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 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
t; libraries.
>
What would we have to do to make PPL and CLooG required to build GCC?
Sebastian Pop
--
AMD - GNU Tools
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
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
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
Hi Grigori,
On Thu, Feb 26, 2009 at 04:57, Grigori Fursin wrote:
> Hello All,
>
> I just saw an announcement that a new Google Summer of Code'2009
> (http://code.google.com/soc) will be accepting project proposals
> in a week or so. My colleagues and I would like to submit a few proposals
> so wa
me an email.
Thanks,
Sebastian Pop
--
AMD - GNU Tools
On Fri, Feb 6, 2009 at 2:49 PM, Diego Novillo wrote:
> Before I can accept patches, however, I need to make sure that
> everyone has copyright assignments on file. I know that Taras, Basile
> and Le-Chun do. Sean and Grigori, do you folks have copyright papers
> already?
Grigori works for INRIA
On Mon, Jan 19, 2009 at 11:27 PM, Ben Elliston wrote:
> On Mon, 2009-01-19 at 23:20 -0600, Sebastian Pop wrote:
>
>> > Perhaps we should add a comment to common.opt to explain this?
>>
>> Yes, we could apply this patch.
>
> Looks good to me (and I think it
On Mon, Jan 19, 2009 at 11:11 PM, Ben Elliston wrote:
>> > Is this an oversight, or are these options deprecated?
>>
>> These options are intentionally not documented: they should not be
>> used by programmers.
>
> Perhaps we should add a comment to common.opt to explain this?
Yes, we could apply
On Mon, Jan 19, 2009 at 10:45 PM, Ben Elliston wrote:
> Hi Sebastian
>
> While reading through the Graphite code on the trunk, I noticed that
> -fgraphite and -fgraphite-identity are no documented in doc/invoke.texi.
> Is this an oversight, or are these options deprecated?
These options are inten
xgcc that doesn't understand "-x c++", and of course target
> libstdc++ hasn't been built yet. Something's really wrong here - I can't
> understand why there's C++ involved or how it could work. Maybe the default
> configure options of PPL have changed to include some C++ interface that
> wasn't built by default at the time the wiki page was written?
>
> Anyway, TIA for any enlightenment anyone can provide. I could file PRs or
> patches for the first two bugs if desired,
I would highly appreciate this.
> but the third part has me totally confused, I don't know what to do
> with it.
I'm forwarding this third question to the PPL folks, hoping that they
already dealt with similar cases and probably already have a solution.
Thanks,
Sebastian Pop
--
AMD - GNU Tools
On Thu, Dec 11, 2008 at 2:36 PM, Sebastian Pop wrote:
> I do know these problems and also the place that I have to fix.
>
> I guess a meta bug like this one "Wrong code with -O3
> -fgraphite-identity on polyhedron benchmarks" is enough.
>
I just opened a bug that
I do know these problems and also the place that I have to fix.
I guess a meta bug like this one "Wrong code with -O3
-fgraphite-identity on polyhedron benchmarks" is enough.
Thanks for testing,
Sebastian Pop
--
AMD - GNU Tools
On Tue, Nov 4, 2008 at 11:45 AM, Roberto Bagnara <[EMAIL PROTECTED]> wrote:
> Jack Howarth wrote:
>>
>> Now that ppl 0.10 is release, what are the plans for merging
>> the cloog-ppl changes into an actual cloog release so that tarballs are
>> available for both?
>
> This is a good question for the
On Tue, Nov 4, 2008 at 7:27 PM, Sebastian Pop <[EMAIL PROTECTED]> wrote:
> *** DEADLINE EXTENDED UNTIL NOVEMBER 21, 2008 ***
...
> Papers due: November 7, 2008
Well, papers are now due by November 21, 2008. Sorry for the typo.
Sebastian
the
workshop may be invited to revise their submission for the
journal Transactions on HiPEAC, if the work is in sufficiently
mature form.
Organizers:
Paul H.J. Kelly, Imperial College of London, UK
Sebastian Pop, AMD, USA
Program Committee:
Albert Cohen, INRIA, France
Grigori Fursin, IN
rs:
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, USA
Jan Hubicka, SuSE, Czech Republic
Paul H.J. Kelly, Imperial College of London, UK
Ondrej Lhotak, Universit
On Sat, Oct 11, 2008 at 6:46 AM, Richard Guenther
<[EMAIL PROTECTED]> wrote:
> Note that we cannot really remove switches from the user, but we have to at
> least keep them as no-op for backward compatibility. Which is why I would
> like you to think twice at least as to what options you want to a
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
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
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
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 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 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
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
pe not years).
Sebastian Pop
--
AMD - GNU Tools
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
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
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
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
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,
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 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 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 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
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
1 - 100 of 187 matches
Mail list logo
