Re: Parallelize the compilation using Threads
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
Re: About GSOC.
About roundeven, there might be need to add case to
expand_builtin_int_roundingfn similar to
ceil, for expansion.
But how is round() expanded since there's no
entry for it in expand_builtin_int_roundingfn ?
Also, is it right to have an added case for roundeven in convert.c
along CASE_FLT_FN (BUILT_IN_ROUND)
in convert_to_integer_1?
Thanks.
On Tue, 23 Oct 2018 at 22:21, Joseph Myers wrote:
>
> On Tue, 23 Oct 2018, Martin Jambor wrote:
>
> > Hi Joseph,
> >
> > this seems related to your proposal GSoC proposal in the beginning
> > of this year. Do you have any comments about Tejas's idea? Do you
>
> My proposal was designed so that it would be possible to do some small
> piece, that is useful by itself, and so learn about some parts of the
> compiler, and then go onto another piece, and so learn about other parts
> of the compiler - as there are lots of separate pieces that are related,
> but each useful by itself as a contribution to GCC. The parts Tejas
> refers to are good pieces to be looking at for one such piece (roundeven
> folding for constant arguments) (along with e.g. builtins.def to define
> the built-in functions).
>
> > think this would be a good (part of) a GSoC project next year?
>
> If a suitable mentor is available for it next year.
>
> > > It does tell that roundeven rounds its argument to nearest integral
> > > ties to even (least significant bit 0) returning integral value
> > > provided that the resulting value is exact.
> > > So, for the start, I'd be implementing this functionality for roundeven.
> > > As ita said in earlier mails that, similar functions like
> > > real_ceil are implemented
> > > in real.c and are used in fold-const-call.c.
> > > Roundeven might be implemented in similar way. Is it built-in
> > > (internal) function means not to be exposed to end-user?
> > > Studying some functions like real_ceil, there are call checks
> > > (flag_errno_math) so I believe similar would be needed for roundeven.
>
> The expectation for this part of the project would be that calls to both
> __builtin_roundeven and roundeven (and similar functions with f, l, f128
> etc. suffixes) would be folded when the arguments are constants (both
> direct calls with constants such as roundeven (2.5), and cases where
> GIMPLE optimization passes propagate a constant into the call, such as
> "double d = 2.5; return roundeven (d);"). This of course involves various
> internal functions in the compiler to implement that.
>
> If you compile code such as
>
> double
> f (void)
> {
> double d = 2.5;
> return ceil (d);
> }
>
> with -O2 -S -fdump-tree-all, you can look at the generated dump files to
> see which optimization pass the folding into constant 3.0 occurs in.
> Looking at such dumps is an important way of finding your way around the
> optimization passes in the compiler.
>
> > > In real.c where real_ceil is implemented, there are function calls
> > > (and implementations) like do_fix_trunc which also then call functions
> > > like decimal_do_dix_trunc (maybe the main functionality of
> > > do_fix_trunc?, other are just checks, like NaN or qNaN). I did not
>
> You can ignore any cases for decimal floating-point values (do gcc_assert
> (!r->decimal)), given that the project does not involve adding any decimal
> floating-point built-in functions. That means you should instead
> understand REAL_EXP and the significands of floating-point values, and
> what functions such as clear_significand_below and test_significand_bit
> do, because you'll need to write your own logic like that in do_fix_trunc,
> with appropriate cases for whether the bits with values 0.5 and below form
> part of the significand.
>
> > > understand these functions really and what do they do. Also I did not
> > > understand the structure of REAL_VALUE_TYPE (r->cl and etc?)
>
> I suggest looking more closely at the definition of cl in real.h. It's
> true that it doesn't have a comment specifying its semantics directly, but
> the /* ENUM_BITFIELD (real_value_class) */ should give a strong hint,
> along with the values that are stored in that field. By looking at how
> all the fields in real_value are used, you should be able to deduce their
> semantics, and then send a GCC patch that adds a comment to each field
> with a more detailed description of its semantics, which would be a useful
> contribution by itself to help people reading real.c code in future.
>
> (struct real_format has more detailed comments on some of the fields. I
> suggest using those as a model for the comments that ought to be written
> for the fields of struct real_value.)
>
> > > Also when does the real.c and fold-const-call.c comes in picture in
> > > the flow of GCC (Is it for GIMPLE level instruction selection (gimple
> > > stmnt to corresponding rtl instruction))?
>
> The code you're looking at is used in GIMPLE optimizations, and possibly
> folding before GIMPLE.
>
> Converting roundeven calls with non-constant arguments to appropriate
> instructio
Re: About GSOC.
On Fri, 16 Nov 2018, Tejas Joshi wrote: > About roundeven, there might be need to add case to > expand_builtin_int_roundingfn similar to > ceil, for expansion. > But how is round() expanded since there's no > entry for it in expand_builtin_int_roundingfn ? Please see the comment above expand_builtin_int_roundingfn, and that above expand_builtin_int_roundingfn_2, which handle different sets of functions. Those functions are of no relevance to adding support for built-in roundeven. (They might be of relevance to support for built-in fromfp functions, depending on whether the detailed semantics allows casts-to-integer of calls to other functions to be converted into calls to the fromfp functions. But I don't think inventing __builtin_lroundeven would be appropriate.) > Also, is it right to have an added case for roundeven in convert.c > along CASE_FLT_FN (BUILT_IN_ROUND) > in convert_to_integer_1? Not until doing things with fromfp functions. There is no lroundeven (for example) in TS 18661-1. -- Joseph S. Myers jos...@codesourcery.com
Re: Parallelize the compilation using Threads
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 using threads"(GSoC 2018 [1]). I > > am a newcommer in GCC, but already have sent some patches, some of > > them have already been accepted [2]. > > > > I brought this subject up in IRC, but maybe here is a proper place to > > discuss this topic. > > > > From my point of view, parallelizing GCC itself will only speed up the > > compilation of projects which have a big file that creates a > > bottleneck in the whole project compilation (note: by big, I mean the > > amount of code to generate). > > That's true. During GCC bootstrap there are some of those (see PR84402). > > One way to improve parallelism is to use link-time optimization where > even single source files can be split up into multiple link-time units. But > then there's the serial whole-program analysis part. Did you mean this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402 ? That is a lot of data :-) It seems that 'phase opt and generate' is the most time-consuming part. Is that the 'GIMPLE optimization pipeline' you were talking about in this thread: https://gcc.gnu.org/ml/gcc/2018-03/msg00202.html > > 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 that the file should be broken > > into smaller files. Finally, the Makefiles will take care of the > > parallelization task. > > What do you mean by GCC must not change the project layout? GCC > happily re-orders functions and link-time optimization will reorder > TUs (well, linking may as well). > That was a response to a comment made on IRC: On Thu, Nov 15, 2018 at 9:44 AM Jonathan Wakely wrote: >I think this is in response to a comment I made on IRC. Giuliano said >that if a project has a very large file that dominates the total build >time, the file should be split up into smaller pieces. I said "GCC >can't restructure people's code. it can only try to compile it >faster". We weren't referring to code transformations in the compiler >like re-ordering functions, but physically refactoring the source >code. Yes. But from one of the attachments from PR84402, it seems that such files exist on GCC, https://gcc.gnu.org/bugzilla/attachment.cgi?id=43440 > > My questions are: > > > > 1. Is there any project compilation that will significantly be improved > > if GCC runs in parallel? Do someone has data about something related > > to that? How about the Linux Kernel? If not, I can try to bring some. > > We do not have any data about this apart from experiments with > splitting up source files for PR84402. > > > 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. > > 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 already benefit from make > parallelism remains a question. As I agree that documenting GCC's global states is good for the community and the development of GCC, I really don't think this a good motivation for parallelizing a compiler from a research standpoint. There must be something or someone that could take advantage of the fine-grained parallelism. But that data from PR84402 seems to have the answer to it. :-) On Thu, Nov 15, 2018 at 4:07 PM Szabolcs Nagy wrote: > > 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 already benefit from make > > parallelism remains a question. > > in the common case (project with many small files, much more than > core count) i'd expect a regression: > > if gcc itself tries to parallelize that introduces inter thread > synchronization and potential false sharing in gcc (e.g. malloc > locks) that does not exist with make parallelism (glibc can avoid > some atomic instructions when a process is single threaded). That is what I am mostly worried about. Or the most costly part is not parallelizable at all. Also, I would expect a regression on very small files, which probably could be avoided implementing this feature as a flag? On Fri, Nov 16, 2018 at 11:05 AM Martin Jambor wrote: > > Hi Giuliano, > > On Thu, Nov 15 2018, Richard Biener wrote: > > You may want to search the mailing list archiv
gcc-8-20181116 is now available
Snapshot gcc-8-20181116 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/8-20181116/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8-branch revision 266224 You'll find: gcc-8-20181116.tar.xzComplete GCC SHA256=d1f6bebe7b3b5189af069dbf90c010a526bc1b76c92d999cf5945caa106ced15 SHA1=6d578bdbb273066318422fd99dce5ae37626bb53 Diffs from 8-20181109 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
