On 27/04/2014 21:52, Roman Gareev wrote:
Hi Tobias,
I'm considering the current code in graphite_clast_to_gimple.c, and
want to ask a few questions about it.
1. Where can I find the definitions of basic_block_def and edge from
coretypes.h?
gcc/basic-block.h
2. Why are recompute_all_domina
Hi Roman,
as you already look very actively through the graphite code, I was
wondering if you already have an idea how to start with the
implementation? It is obviously a good idea to first browse the code
and get a general picture of the existing implementation as it helps to
get a good pictu
On 06/05/2014 10:19, Richard Biener wrote:
Hi Richi,
thanks for the comments.
On Tue, May 6, 2014 at 8:57 AM, Tobias Grosser wrote:
On 05/05/2014 21:11, Roman Gareev wrote:
Hi Tobias,
thank you for your reply! I have questions about types. Could you
please answer them?
I looked
On 06/05/2014 13:52, Richard Biener wrote:
On Tue, May 6, 2014 at 1:02 PM, Tobias Grosser wrote:
On 06/05/2014 10:19, Richard Biener wrote:
Hi Richi,
thanks for the comments.
On Tue, May 6, 2014 at 8:57 AM, Tobias Grosser wrote:
On 05/05/2014 21:11, Roman Gareev wrote:
Hi Tobias
On 12/05/2014 20:35, Roman Gareev wrote:
Hi Tobias,
thank you for your advice!
On the other side, I think it is a good idea to simultaneously keep track of
the design you have in mind and the first steps you are planning to take.
Even though the full design may still need some time,
some basic
On 17/05/2014 00:27, Maxim Kuvyrkov wrote:
Hi Community,
The community bonding period is coming to a close, students can officially
start coding on Monday, May 19th.
In the past month the student should have applied for FSF copyright assignment
and, hopefully, executed on a couple of test t
On 17/05/2014 00:43, Maxim Kuvyrkov wrote:
On May 17, 2014, at 10:41 AM, Tobias Grosser wrote:
On 17/05/2014 00:27, Maxim Kuvyrkov wrote:
Hi Community,
The community bonding period is coming to a close, students can officially
start coding on Monday, May 19th.
In the past month the
On 16/05/2014 21:49, Roman Gareev wrote:
Hi Tobias,
what is the difference you see between ISL AST generation and code
generation?
By “ISL AST generation”, I mean ISL AST generation without generation
of GIMPLE code.
Alright.
What are your plans to separate the ISL AST generation? Do you
On 25/05/2014 13:12, Roman Gareev wrote:
Hi Tobias,
I tried to incorporate all your comments in the following patch. It
also contains traversing of ISL AST and its dump to a file. You can
find out more about this at the following link
http://romangareev.blogspot.ru/2014/05/gsoc-report-i.html
On 01/06/2014 01:21, Roman Gareev wrote:
Hi Tobias,
Allright. It seems you understood the tree traversel. For the actual
patch that we want to commit, let's leave it out for now. Instead,
let's try to get a minimal patch that only adds the flag and the new
file for the isl_ast stuff. In case
On 08/06/2014 19:43, Roman Gareev wrote:
Hi Tobias,
This file is empty. It seems to be the perfect place for gloog_isl,
maybe give it a more descriptive name. E.g.,
graphite_regenerate_ast_isl()
We could then rename gloog, to graphite_regenerate_ast_cloog().
gloog comes from graphite + cloog
On 18/06/2014 15:22, Roman Gareev wrote:
Hi Tobias,
I made a separate patch and rebased the previous one. They are
attached to this letter.
I am surprised. Are all these includes really needed to get _this_ patch
compile? (I asked this before).
I saw your previous comment related to this an
On Jun 18, 2014 6:03 PM, Roman Gareev wrote:
>
> I used trunk and compiled these patches only with isl 0.12 and ClooG
> 0.18.1. Which versions of these libraries are need to be checked for
> compatibility?
That's fine. Please post the patches for wider review at gcc patches. Also
mention that
On 23/06/2014 08:34, Roman Gareev wrote:
Hi Tobias,
I'm currently working on generation of GCC expression trees from isl
ast expressions . Could you please answer a few questions about it?
1. How is it better to generate tree from isl_ast_expr_int? In the
temporary variant I call isl_ast_expr_g
On 27/06/2014 07:31, Roman Gareev wrote:
Are you saying we should better not do unit testing at the moment? (This is
perfectly fine with me, I am just verifying what you said)
Yes, I think we should better not to do it. It seems that unit-testing
isn't supported in gcc.
If we don't have a con
On 01/07/2014 14:53, Roman Gareev wrote:
Hi Tobias,
could you please advise me how to verify the results of gimple code
generation?
More comments inline, but here something on a very high level.
I personally like testing already on the GIMPLE level and could see us
matching for certain expres
On 03/07/2014 19:24, Roman Gareev wrote:
However, this form doesn't have loop guards which are generated by
>>graphite_create_new_loop_guard in gcc/graphite-isl-ast-to-gimple.c and
>>by graphite_create_new_loop_guard in graphite-clast-to-gimple.c.
>
>
>Maybe the guards are directly constant fold
On 03/07/2014 19:23, Roman Gareev wrote:
Dear gcc contributors,
could you please answer a few questions about std::map? Does gcc have
a policy that forbids using of map in the source code of gcc? Can this
using create a new installation dependency, which requires libstdc++?
I would be very grate
On 04/07/2014 04:16, Trevor Saunders wrote:
On Thu, Jul 03, 2014 at 07:52:59PM +0200, Tobias Grosser wrote:
On 03/07/2014 19:23, Roman Gareev wrote:
Dear gcc contributors,
could you please answer a few questions about std::map? Does gcc have
a policy that forbids using of map in the source
On 05/07/2014 00:03, Trevor Saunders wrote:
On Fri, Jul 04, 2014 at 09:57:11AM +0200, Tobias Grosser wrote:
On 04/07/2014 04:16, Trevor Saunders wrote:
On Thu, Jul 03, 2014 at 07:52:59PM +0200, Tobias Grosser wrote:
On 03/07/2014 19:23, Roman Gareev wrote:
Dear gcc contributors,
could you
On 07/07/2014 12:33, Roman Gareev wrote:
Hi Tobias,
I think that, according to the std::map feedback, we could use
std::map now and replace it with hash_map later, if its performance is
better. However, I propose to temporary postpone this and work on
gimple code generation from isl_ast_node_use
[Forgot to answer two questions]
On 07/07/2014 12:33, Roman Gareev wrote:
Hi Tobias,
I think that, according to the std::map feedback, we could use
std::map now and replace it with hash_map later, if its performance is
better.
Right.
> However, I propose to temporary postpone this and work o
On 07/07/2014 13:14, Jonathan Wakely wrote:
On 7 July 2014 12:08, Tobias Grosser wrote:
The number of elements in these maps is most likely between 3-10.
Then std::map is the wrong solution.
The overhead of dereferencing all the pointers while walking through a
std::map will be higher than
On 08/07/2014 14:50, Roman Gareev wrote:
You may want to take a look at polly commit r212186, where I reworked
and documented how this works.
It is much easier for understanding. Thank you! I've tried to consider
an older version.
Is this necessary? The id should already be set in
(graphite-s
This is not a patch review, lets move this to gcc@gcc.gnu.org.
On 15/07/2014 17:03, Roman Gareev wrote:
I've found out that int128_integer_type_node and
long_long_integer_type_node are NULL at the moment of definition of
the graphite_expression_size_type. Maybe we should use
long_long_integer_ty
On 16/07/2014 11:40, Richard Biener wrote:
On Tue, Jul 15, 2014 at 5:45 PM, Tobias Grosser wrote:
This is not a patch review, lets move this to gcc@gcc.gnu.org.
On 15/07/2014 17:03, Roman Gareev wrote:
I've found out that int128_integer_type_node and
long_long_integer_type_node are NU
On 21/07/2014 14:23, Roman Gareev wrote:
I've attached the patch, which contains generation of Gimple code from
isl_ast_node_block.
However, I've found out a problem. The following example:
int k = 50;
static int __attribute__((noinline))
foo ()
{
int i, res;
for (i = 0, res = 0; i < k; i
On 21/07/2014 14:55, Roman Gareev wrote:
It seems S_6 is now scheduled before S_4 which is surprising, as
dependences from S_4 to S_6 should prevent us from generating a schedule
that yields such a result. What is the schedule that you give to the isl ast
generator?
The schedule generated by th
On 31/07/2014 16:41, Roman Gareev wrote:
Tobias, could you please advise me how is it better to determine a
depth for loop (it is necessary for loop_is_parallel_p)? In
graphite-clast-to-gimple.c. it is done by using the number of
dimensions of a domain, which is attached to clast_for. As far as I
On 04.11.2014 16:17, Tobias Burnus wrote:
Hi all,
currently, contrib/download_prerequisites downloads isl-0.12.2 from
ftp://gcc.gnu.org/pub/gcc/infrastructure/$ISL.tar.bz2
However, that version has a bug which causes an ICE (PR 62289).
End of October, ISL 0.14 was released, which should contain
On 06.11.2014 07:04, Roman Gareev wrote:
CLooG is not necessarily needed. You can run graphite just with ISL. The
main reason that ISL code generation is not enabled by default is that we
did not yet get extensive testing and it was unclear who will have the time
to fix possible bugs.
Could you
On 06.11.2014 10:05, Richard Biener wrote:
On Thu, Nov 6, 2014 at 8:02 AM, Tobias Grosser wrote:
On 06.11.2014 07:04, Roman Gareev wrote:
CLooG is not necessarily needed. You can run graphite just with ISL. The
main reason that ISL code generation is not enabled by default is that we
did not
On 06.11.2014 11:15, Richard Biener wrote:
On 11/6/14, Tobias Grosser wrote:
On 06.11.2014 10:05, Richard Biener wrote:
On Thu, Nov 6, 2014 at 8:02 AM, Tobias Grosser wrote:
On 06.11.2014 07:04, Roman Gareev wrote:
CLooG is not necessarily needed. You can run graphite just with ISL.
The
On 06.11.2014 20:08, Roman Gareev wrote:
As the ISL code generator has been default since a while and we did not get
many bug reports, the actual switch seems to have worked well. We could
probably still need some testing, but in this case it is most likely time to
drop the CLooG support entirely
On 08.11.2014 20:49, Roman Gareev wrote:
Sounds good as long as they will compile and pass tests independently.
Please also remember updating the documentation.
I’m trying to build Graphite without CLooG, but I get the following error:
libbackend.a(graphite-optimize-isl.o): In function `getSch
On Mon, Aug 21, 2017, at 05:31, Leslie Zhai via llvm-dev wrote:
> Hi LLVM and GCC developers,
>
> My sincere thanks will goto:
>
> * Duncan, the core developer of llvm-gcc and dragonegg
> http://llvm.org/devmtg/2009-10/Sands_LLVMGCCPlugin.pdf
>
> * David, the innovator and developer of GCC
> h
Hi Leslie,
I copied you in this thread as you currently worked quite a bit with
dragonegg and we are currently trying to generate metadata that makes it
easier to reason about multi-dimensional fortran arrays.
Best,
Tobias
On Mon, Sep 4, 2017, at 23:06, (IIIT) Siddharth Bhat wrote:
> Hello,
>
>
Thank you leslie!
Best,
Tobias
On Wed, Sep 6, 2017, at 05:25, Leslie Zhai wrote:
>
>
> 在 2017年09月05日 15:25, Leslie Zhai 写道:
> >
> >
> > 在 2017年09月05日 14:14, Tobias Grosser 写道:
> >> Hi Leslie,
> >>
> >> I copied you in this thread as you c
On Tue, 2009-07-14 at 23:34 +0200, Richard Guenther wrote:
> On Tue, Jul 14, 2009 at 6:08 PM, Sebastian Pop wrote:
> > 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
On Wed, 2009-07-15 at 13:26 +0200, Richard Guenther wrote:
> On Wed, Jul 15, 2009 at 1:00 PM, Tobias
> Grosser wrote:
> > On Tue, 2009-07-14 at 23:34 +0200, Richard Guenther wrote:
> >> On Tue, Jul 14, 2009 at 6:08 PM, Sebastian Pop wrote:
> >> > On Tue, Jul 14, 2
On Wed, 2009-07-15 at 22:48 +0200, Richard Guenther wrote:
> On Wed, Jul 15, 2009 at 10:46 PM, Richard
> Guenther wrote:
> > On Wed, Jul 15, 2009 at 9:15 PM, Tobias
> > Grosser wrote:
> >>> A note on Lis final graph algorithm. I don't understand why you want
&
Hi Toon,
did you build with the latest cloog-ppl package. It is 0.15.7 and
available at ftp://gcc.gnu.org/pub/gcc/infrastructure/.
Gcc should build without any problems using this package. Can you verify
this?
The problem was in the cloog-ppl headers and was fixed in CLooG-ppl
0.15.4 (I think).
I try to analyse this code:
--
int foo (int N)
{
int ftab[257];
int i, j;
for (i = 0; i < N - 7488645; i++)
j = ftab [i];
return j;
}
--
The number of iterations I get is:
(unsig
On Wed, 2009-10-07 at 16:42 +0200, Richard Guenther wrote:
> On Wed, Oct 7, 2009 at 4:37 PM, Tobias Grosser
> wrote:
> > I try to analyse this code:
> > --
> > int foo (int N)
> > {
> > int ftab[257];
>
On Wed, 2009-10-07 at 17:23 +0200, Richard Guenther wrote:
> On Wed, Oct 7, 2009 at 5:16 PM, Tobias Grosser
> wrote:
> > On Wed, 2009-10-07 at 16:42 +0200, Richard Guenther wrote:
> >> On Wed, Oct 7, 2009 at 4:37 PM, Tobias Grosser
> >> wrote:
>
On Wed, 2009-10-07 at 18:30 +0200, Tobias Grosser wrote:
> On Wed, 2009-10-07 at 17:44 +0200, Richard Guenther wrote:
> > On Wed, Oct 7, 2009 at 5:35 PM, Tobias Grosser
> > wrote:
> > > On Wed, 2009-10-07 at 17:23 +0200, Richard Guenther wrote:
> > >> On
On Thu, 2009-10-08 at 08:49 +0200, Zdenek Dvorak wrote:
> Hi,
>
> > > Ah, indeed. Sorry for being confused. Is tree-niter-desc->assumptions
> > > or ->may_be_zero non-NULL?
> >
> > Yes both. I attached the gdb content for both.
>
> you need to check may_be_zero, which in your case should conta
On Sun, 2009-10-11 at 20:20 +0530, sandeep soni wrote:
> Hi All,
>
> I have been studying the gcc code lately as part of my project.I have
> got info from this mailing list about CFG and DFG information.I want
> to know how gcc uses this information to perform loop optimization?
> Does it Follow a
On Wed, 2009-10-14 at 20:12 +0530, sandeep soni wrote:
> > Hi,
> >
> > you also might want to take a look at the Graphite project.
> > http://gcc.gnu.org/wiki/Graphite where we do loop optimizations and
> > automatic parallelization based on the polytop model. If you need any
> > help feel free to
On Wed, 2009-10-14 at 23:56 +0530, sandeep soni wrote:
> On Wed, Oct 14, 2009 at 9:02 PM, Tobias Grosser
> wrote:
> > On Wed, 2009-10-14 at 20:12 +0530, sandeep soni wrote:
> >> > Hi,
> >> >
> >> > you also might want to take a look at the Graphite
On Fri, 2009-12-04 at 10:29 -0600, Sebastian Pop wrote:
> 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 co
On Fri, 2009-12-04 at 10:50 -0600, Sebastian Pop wrote:
> 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
On 09.02.2010 19:39, Sebastian Pop wrote:
> 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
>
Hi Artem,
On 04/23/10 22:22, Artem Shinkarov wrote:
Hi
I've submitted an application to gcc in terms of Google Summer of Code
2010, but I have not received any comments yet. The idea of this
application was discussed here in the mailing list and I received
quite some support.
If people are sti
Hi graphities,
graphite consists of four flags "-floop-block", "-floop-interchange",
"-floop-stripmine" and "-fgraphite".
If any of these flags is set, we enable the graphite pass and we search
for SCoPs.
For every SCoP we try to apply transformations specified with
"-floop-block", "-floop-interc
On Fri, 2008-10-10 at 20:35 +0200, Manuel López-Ibáñez wrote:
> 2008/10/10 Tobias Grosser <[EMAIL PROTECTED]>:
> >
> > Now:
> >
> >
> > -fgraphite: Do nothing.
> > -floop-block, -floop-interchange, -floop-stripmine: Try these
> > transformat
On Fri, 2008-10-10 at 13:49 -0500, Jagasia, Harsha wrote:
> Hi Tobias,
> >
> >graphite consists of four flags "-floop-block", "-floop-interchange",
> >"-floop-stripmine" and "-fgraphite".
> >
> >If any of these flags is set, we enable the graphite pass and we search
> >for SCoPs.
> >For every SCoP
On Fri, 2008-10-10 at 13:51 -0500, Jagasia, Harsha wrote:
> >
> >Hi Tobias,
> >>
> >>graphite consists of four flags "-floop-block", "-floop-interchange",
> >>"-floop-stripmine" and "-fgraphite".
>
> In fact I also think that we should not expose "-floop-stripmine" as a
> flag because by itself it
ocking.
This should make debugging of the current bug reports easier and allows
us to set up nightly tests testing the complete front and backend.
This patch implements solution two of the recent discussion at [EMAIL PROTECTED]
See you
Tobi
2008-10-10 Tobias Grosser <[EMAIL PROTECTED]
Hi,
On Fri, 2008-10-10 at 23:31 +0200, Albert Cohen wrote:
> Tobias Grosser wrote
> > Hi graphities,
> >
> > graphite consists of four flags "-floop-block", "-floop-interchange",
> > "-floop-stripmine" and "-fgraphite".
> &
On Sat, 2008-10-11 at 23:19 +0200, Richard Guenther wrote:
> On Sat, Oct 11, 2008 at 11:13 PM, Sebastian Pop <[EMAIL PROTECTED]> wrote:
> > 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
with loop blocking
-fgraphite-interchange: Loop interchange (unimplemented).
Useful for checking available performance
improvements with loop interchange.
Later I would like to be -fgraphite the automatic optimizer.
See you
Tobi
Hi,
On Sun, 2008-10-12 at 13:19 +0200, Tobias Burnus wrote:
> Hi,
>
> Tobias Grosser wrote:
> > another patch. It contains:
> >
> > - Removal of documentation outside of common.opts for (-fgraphite,
> > -floop-block, -floop-interchange, -floop-strip-mine)
Hi Razya
great to hear these Graphite plans. Some short comments.
On Tue, 2009-03-10 at 16:13 +0200, Razya Ladelsky wrote:
> [...]
>
> The first step, as we see it, will teach Graphite that parallel code needs
> to be produced.
> This means that Graphite will recognize simple parallel loops (us
Hi Ian,
> Student applications will be accepted from March 23 to April 3. Each
> student will work with a mentor from the project. As we've done in past
> years, we need to have a set of mentors who are prepared to work with
> students. I would like to encourage any interested experienced GCC
>
Hi Pranav,
On Tue, 2009-03-24 at 23:32 +0530, Pranav wrote:
> Hi Sebastian and Tobias,
[...]
> To delve deeper into compiler's research I will be joining the graduate
> school at UIUC from next Fall. I feel that working on this project would
> give me great pleasure and it would be the best wa
On Thu, 2009-03-26 at 10:36 +0800, Li Feng wrote:
> Hi all,
>
> Below is the proposal of this gSoc project. I'd really like you review and
> comment on this and then I can plan this project better.
Hi Li,
this looks nice. Thanks for your work on this.
Tobias
>
> Thanks,
> Li Feng
> -
Hi,
to keep everybody updated what is happening in the GRAPHITE branch, I
would like to post the notes of our weekly phone call.
Attendees: Razya, Li, Konrad, Jan, Tobi, David, Sebastian, Christophe
Discussed topics:
* Data dependencies: Tobias committed a patch filling the access
gt; > --- On Wed, 4/22/09, Li Feng
> > wrote:
> >
> > > From: Li Feng
> > > Subject: [gSoc] [graphite] general plan for Automatic
> > parallelization in Graphite
> > > To: "GCC"
> > > Cc: "Tobias Grosser"
> >
On Mon, 2009-04-27 at 19:58 +0100, Dave Korn wrote:
> Cristianno Martins wrote:
>
> > Well, I didn't find anything about a implementation of this kind of
> > optimization inside of gcc. Also, I need to know if someone is working
> > on something like this using the gcc compiler.
>
> http://gcc.gn
get started with Graphite - just drop us a line.
Tobias
> Thanks in advance,
>
> On Mon, Apr 27, 2009 at 6:46 PM, Tobias Grosser wrote:
> > On Mon, 2009-04-27 at 19:58 +0100, Dave Korn wrote:
> >> Cristianno Martins wrote:
> >>
> >> > Well, I didn
Hi gcc developers, hi graphities
here are some notes from our weekly phone call. Unfortunately I missed
to send out the notes from the last two phone calls, but I hope to get
them out more regulary. Believe in me! ;-)
http://gcc.gnu.org/wiki/Graphite_Phone_Call/2009_04_29
Attendees: Li, Jan, Kon
On Wed, 2009-04-29 at 23:57 +0200, Richard Guenther wrote:
> On Wed, Apr 29, 2009 at 11:34 PM, Tobias Grosser
> wrote:
> > Hi gcc developers, hi graphities
> >
> > here are some notes from our weekly phone call. Unfortunately I missed
> > to send out the notes from t
Hi folks, hi graphities,
here you are with the latest notes from our graphite phone call.
It is also available on the wiki:
http://gcc.gnu.org/wiki/Graphite_Phone_Call/2009_05_06
All the best
Tobi
Attendees: Sebastian, Tobias, Christophe, Albert, Li, Jan, Razya,
Konrad, Antoniu
* Seb
y project
> focus on multicore architectures; I guess this is not a problem, is
> it?
Hey Christiano,
I have not heard anything from you for a while. How is your project
going?
Tobi
>
> Thanks in advance,
>
> On Mon, Apr 27, 2009 at 6:46 PM, Tobias Grosser wrote:
> >
Hi,
On 05/09/10 05:09, ajmcello wrote:
I've got a quad core 3.2Ghz FreeBSD-8 system with 8GB of ram. I
compiled and installed Cloog-PPL and PPL, mpfr, gmp, mpc, polylib,
etc. I'm using make -j 4, and my gcc compile has been going for about
24 hours. Is this normal or did something go terribly wr
On 06/17/2010 10:41 AM, Simone Pellegrini wrote:
Dear all,
I was reading one of the first technical reports of GRAPHITE and it
looks like several libraries have been considered for integration into
GCC for solving the ILP problem and polyhedral model representation. In
the document the Omega libr
On 01/27/2014 08:29 PM, Tobias Burnus wrote:
Hello,
motivated by the recent MPC 1.0.2 announcement, I looked at
./contrib/download_prerequisites and also at
ftp://gcc.gnu.org/pub/gcc/infrastructure/ to see which versions are
offered there.
Question: Would it make sense to place newer versions i
On 02/03/2014 11:11 AM, Роман Гареев wrote:
Dear Graphite contributors,
I am new to Graphite and want to find out if I could work on it. Could you
point me to a simple bug, please? I would be very grateful for your advise.
Hi,
maybe this bug seems a good start:
http://gcc.gnu.org/bugzil
On 02/04/2014 07:08 PM, Roman Gareev wrote:
Thank you for your advice! I've started working on a fix.
Great. Feel free to ask in case you need some help.
Tobias
On 02/13/2014 08:19 AM, Richard Biener wrote:
On Mon, Jan 27, 2014 at 8:40 PM, Tobias Grosser wrote:
On 01/27/2014 08:29 PM, Tobias Burnus wrote:
Hello,
motivated by the recent MPC 1.0.2 announcement, I looked at
./contrib/download_prerequisites and also at
ftp://gcc.gnu.org/pub/gcc
On 02/13/2014 08:37 AM, Richard Biener wrote:
On Thu, Feb 13, 2014 at 2:20 PM, Tobias Grosser wrote:
On 02/13/2014 08:19 AM, Richard Biener wrote:
On Mon, Jan 27, 2014 at 8:40 PM, Tobias Grosser wrote:
On 01/27/2014 08:29 PM, Tobias Burnus wrote:
Hello,
motivated by the recent MPC
On 02/12/2014 11:51 AM, Roman Gareev wrote:
Hi Roman,
thanks for the quick feedback!
I've found out that this bug appeared in revision 189156
(svn://gcc.gnu.org/svn/gcc/trunk)
and similar error message appeared in revision 191757
(svn://gcc.gnu.org/svn/gcc/trunk)
(maybe it's because of chang
On 02/17/2014 06:50 PM, Roman Gareev wrote:
Hi Tobias,
thanks for the answer!
Hi Roman,
sorry for missing this mail.
I think that the segfault is being caused by NULL arguments being passedto
compute_deps
by loop_level_carries_dependences. *This is **causing **an* *assignment of**
On 03/02/2014 08:06 PM, Roman Gareev wrote:
Yes, this would be a 'solution'. However, I am in fact surprised that
those variables are NULL at all. Do you have an idea why this is the
case? Understanding this would help to understand if the patch you
propose is actually the right solution or if
On 02/17/2014 06:50 PM, Roman Gareev wrote:
Hi Tobias,
thanks for the answer!
I think that the segfault is being caused by NULL arguments being passedto
compute_deps
by loop_level_carries_dependences.*This is **causing **an* *assignment of**
NULL values to the following parameters of
On 03/14/2014 09:21 PM, Roman Gareev wrote:
Dear gcc contributors,
I am going to try to participate in Google Summer of Code 2014. My
project is "Integration of ISL code generator into Graphite".
My proposal can be found at on the following link
https://drive.google.com/file/d/0B2Wloo-931AoTWl
On 03/14/2014 09:18 PM, Roman Gareev wrote:
Dear gcc contributors,
I am going to try to participate in Google Summer of Code 2014. My project
is "Integration of ISL code generator into Graphite".
My proposal can be found at on the following link
https://drive.google.com/file/d/0B2Wloo-931AoTWlk
On 03/21/2014 12:04 PM, Roman Gareev wrote:
Hi Tobias,
thank you for all your comments! I've tried to consider them in the
improved version of my proposal, which can be found at the following
link
https://drive.google.com/file/d/0B2Wloo-931AoeUlYOHhETVBvY3M/edit?usp=sharing
.
- In unreleased
On 03/24/2014 02:08 PM, Mircea Namolaru wrote:
Hi,
1. Maybe there is also an opportunity to improve the design of Graphite
code generation, this will give you another benefit - code more robust, easier
to maintain and extend.
I suggest a design where the code generation from ISL AST is based
on
On 03/28/2014 03:52 PM, K_s, Vishnu wrote:
Hi all,
Some of the tests added in gcc.dg/graphite are failing for AVR target, Because
size of the arrays defined are 'too' large for AVR. I'm wondering is it
possible to reduce the size of the array's in tests.
One example is gcc.dg/graphite/scop-0.c,
On 03/31/2014 06:25 AM, Vladimir Kargov wrote:
On 27 March 2014 18:39, Mircea Namolaru wrote:
The domain is computed on basis of the information provided by
number_of_latch_execution that returns the tree expression
(unsigned int) maxLen_6(D) - (unsigned int) minLen_4(D)
For signed integers (
On 03/31/2014 10:10 AM, Richard Biener wrote:
On Mon, Mar 31, 2014 at 8:23 AM, Tobias Grosser wrote:
On 03/31/2014 06:25 AM, Vladimir Kargov wrote:
Regarding this bug there are two directions to go:
1) It is necessary to understand if we need to do wrapping on the result of
Hi,
it has been quiet around Graphite for a while and I think it is more
than time to give an update on Graphite.
== The Status of Graphite ==
Graphite has been around for a while in GCC. During this time a lot of
people tested Graphite and Sebastian fixed many bugs. As of today the
Graphit
On 02/09/2012 11:05 PM, Vladimir Makarov wrote:
On 02/09/2012 07:42 AM, Tobias Grosser wrote:
== Who will do all the work? ==
After reading all the open projects you may wander who will do all the
work? Unfortunately Sebastian switched jobs at the end of 2011, such
that we lost one full time
On 02/09/2012 11:37 PM, Tobias Grosser wrote:
On 02/09/2012 11:05 PM, Vladimir Makarov wrote:
On 02/09/2012 07:42 AM, Tobias Grosser wrote:
== Who will do all the work? ==
After reading all the open projects you may wander who will do all the
work? Unfortunately Sebastian switched jobs at
On 02/10/2012 01:58 AM, Vladimir Makarov wrote:
On 12-02-09 5:54 PM, Tobias Grosser wrote:
On 02/09/2012 11:37 PM, Tobias Grosser wrote:
On 02/09/2012 11:05 PM, Vladimir Makarov wrote:
On 02/09/2012 07:42 AM, Tobias Grosser wrote:
== Who will do all the work? ==
After reading all the open
On 02/17/2012 08:34 PM, David Malcolm wrote:
On Thu, 2012-02-16 at 19:17 -0400, Arnaldo wrote:
Hello everyone,
I'm working on an extension to the Graphite pass of GCC 4.4.0. My
intention is to associate costs to RTL instructions by adding them as
RTX attributes to a machine description file, a
On 03/02/2012 08:40 PM, Dennis Clarke wrote:
If all goes well, I'd like to release 4.7.0 in about three weeks.
I'll drop it on Solaris. Give it a push. Do we realy really need that
ppl/cloog stuff? I have never seen it build and pass any tests, ever,
even once, on Solaris with or without Sun St
On 06/22/2012 12:41 PM, Richard Guenther wrote:
On Thu, Mar 1, 2012 at 3:21 PM, Richard Guenther
wrote:
On Thu, Feb 9, 2012 at 1:42 PM, Tobias Grosser wrote:
Hi,
it has been quiet around Graphite for a while and I think it is more than
time to give an update on Graphite.
== The Status of
1 - 100 of 122 matches
Mail list logo
