On Tue, 2019-02-12 at 15:12 +0100, Richard Biener wrote:
> On Mon, Feb 11, 2019 at 10:46 PM Giuliano Belinassi
> wrote:
> >
> > Hi,
> >
> > I was just wondering what API should I use to spawn threads and
> > control
> > its flow. Should I use OpenMP, pthreads, or something else?
> >
> > My poin
On Mon, Feb 11, 2019 at 10:46 PM Giuliano Belinassi
wrote:
>
> Hi,
>
> I was just wondering what API should I use to spawn threads and control
> its flow. Should I use OpenMP, pthreads, or something else?
>
> My point what if we break compatibility with something. If we use
> OpenMP, I'm afraid th
Hi,
I was just wondering what API should I use to spawn threads and control
its flow. Should I use OpenMP, pthreads, or something else?
My point what if we break compatibility with something. If we use
OpenMP, I'm afraid that we will break compatibility with compilers not
supporting it. On the ot
Hi,
Since gimple-match.c takes so long to compile, I was wondering if it
might be possible to reorder the compilation so we can push its
compilation early in the dependency graph.
I've attached a graphic showing what I mean and the methodology into
PR84402 (https://gcc.gnu.org/bugzilla/show_bug.c
On Tue, Jan 15, 2019 at 10:45 PM Giuliano Belinassi
wrote:
>
> Hi
>
> I've managed to compile gimple-match.c with -ftime-report, and "phase opt and
> generate" seems to be what takes most of the compilation time. This is
> captured
> by the "TV_PHASE_OPT_GEN" timevar, and all its occurrences seem
Hi
I've managed to compile gimple-match.c with -ftime-report, and "phase opt and
generate" seems to be what takes most of the compilation time. This is captured
by the "TV_PHASE_OPT_GEN" timevar, and all its occurrences seem to be in
toplev.c and lto.c. Any ideas of which part such that this varia
On Mon, Jan 14, 2019 at 12:41 PM Giuliano Belinassi
wrote:
>
> Hi,
>
> I am currently studying the GIMPLE IR documentation and thinking about a
> way easily gather the timing information. I was thinking about about
> adding this feature to gcc to show/dump the elapsed time on GIMPLE. Does
> this m
Hi,
I am currently studying the GIMPLE IR documentation and thinking about a
way easily gather the timing information. I was thinking about about
adding this feature to gcc to show/dump the elapsed time on GIMPLE. Does
this makes sense? Is this already implemented somewhere? Where is a good
way to
On Wed, Dec 12, 2018 at 4:46 PM Giuliano Augusto Faulin Belinassi
wrote:
>
> Hi, I have some news. :-)
>
> I replicated the Martin Liška experiment [1] on a 64-cores machine for
> gcc [2] and Linux kernel [3] (Linux kernel was fully parallelized),
> and I am excited to dive into this problem. As a
Hi,
See comments inline.
On 12/13, Bin.Cheng wrote:
> On Wed, Dec 12, 2018 at 11:46 PM Giuliano Augusto Faulin Belinassi
> wrote:
> >
> > Hi, I have some news. :-)
> >
> > I replicated the Martin Liška experiment [1] on a 64-cores machine for
> > gcc [2] and Linux kernel [3] (Linux kernel was fu
On Wed, Dec 12, 2018 at 11:46 PM Giuliano Augusto Faulin Belinassi
wrote:
>
> Hi, I have some news. :-)
>
> I replicated the Martin Liška experiment [1] on a 64-cores machine for
> gcc [2] and Linux kernel [3] (Linux kernel was fully parallelized),
> and I am excited to dive into this problem. As
Hi, I have some news. :-)
I replicated the Martin Liška experiment [1] on a 64-cores machine for
gcc [2] and Linux kernel [3] (Linux kernel was fully parallelized),
and I am excited to dive into this problem. As a result, I want to
propose GSoC project on this issue, starting with something like:
On Fri, Nov 16, 2018 at 8:00 PM Giuliano Augusto Faulin Belinassi
wrote:
>
> Hi! Sorry for the late reply again :P
>
> On Thu, Nov 15, 2018 at 8:29 AM Richard Biener
> wrote:
> >
> > On Wed, Nov 14, 2018 at 10:47 PM Giuliano Augusto Faulin Belinassi
> > wrote:
> > >
> > > As a brief introduction
Hi! Sorry for the late reply again :P
On Thu, Nov 15, 2018 at 8:29 AM Richard Biener
wrote:
>
> On Wed, Nov 14, 2018 at 10:47 PM Giuliano Augusto Faulin Belinassi
> wrote:
> >
> > As a brief introduction, I am a graduate student that got interested
> >
> > in the "Parallelize the compilation usi
Hi Giuliano,
On Thu, Nov 15 2018, Richard Biener wrote:
> You may want to search the mailing list archives since we had a
> student application (later revoked) for the task with some discussion.
Specifically, the whole thread beginning with
https://gcc.gnu.org/ml/gcc/2018-03/msg00179.html
Martin
On 15/11/18 10:29, Richard Biener wrote:
> In my view (I proposed the thing) the most interesting parts are
> getting GCCs global state documented and reduced. The parallelization
> itself is an interesting experiment but whether there will be any
> substantial improvement for builds that can alre
On 11/15/18 3:29 AM, Richard Biener wrote:
>
>> 2. Did I correctly understand the goal of the parallelization? Can
>> anyone provide extra details to me?
>
> You may want to search the mailing list archives since we had a
> student application (later revoked) for the task with some discussion.
>
On Thu, 15 Nov 2018 at 10:29, Richard Biener wrote:
>
> On Wed, Nov 14, 2018 at 10:47 PM Giuliano Augusto Faulin Belinassi
> wrote:
> > Additionally, I know that GCC must not
> > change the project layout, but from the software engineering perspective,
> > this may be a bad smell that indicates t
On Wed, Nov 14, 2018 at 10:47 PM Giuliano Augusto Faulin Belinassi
wrote:
>
> As a brief introduction, I am a graduate student that got interested
>
> in the "Parallelize the compilation using threads"(GSoC 2018 [1]). I
> am a newcommer in GCC, but already have sent some patches, some of
> them ha
19 matches
Mail list logo
