Re: Emit a variable defined in gcc
On 7/2/20 8:12 AM, Harshit Sharma wrote: Thanks Martin. I liked your idea of using __builtin___asan_version_mismatch_check_v8(). But now, I am getting a compile error. ( error: implicit declaration of function '__builtin___asan_version_mismatch_check_v8'; ) It means the reference to this function is not resolved. So, I guess gcc is not emitting this function. The function is defined in libasan.so in libsanitizer/asan/asan_rtl.cpp. What could be the issue here? Btw I am using fsanitize=kernel-address for my project. Even if I use fsanitize=address, the reference to this function will not be resolved. For kernel-address, there's no run-time provided by GCC and so that the call to __builtin___asan_version_mismatch_check_v8 is not emitted. You may change the emission and do it also for kernel-address where you'll define the symbol in kernel source code. Martin
GNU MPFR 4.1.0 Release Candidate 2
The release of GNU MPFR 4.1.0 ("épinards à la crème") is imminent.
Please help to make this release as good as possible by downloading
and testing this release candidate:
https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0-rc2.tar.xz
https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0-rc2.tar.bz2
https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0-rc2.tar.gz
https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0-rc2.zip
The SHA1 digests:
f6320390ed7e79c5310bc1249b4b821c20669033 mpfr-4.1.0-rc2.tar.bz2
e589b42226d80227f8662eed5202e10961337526 mpfr-4.1.0-rc2.tar.gz
2ec87a25c9ed866c2864137f533de4d86b7a8d8f mpfr-4.1.0-rc2.tar.xz
a8aec8a2a70c83e384a7173617030ec46139bdb8 mpfr-4.1.0-rc2.zip
The SHA256 digests:
468cc2ab74caf97ab1f35c5f015297bc3be2dd26e8854f4314d8dacdd6631928
mpfr-4.1.0-rc2.tar.bz2
2fd45c229022d07487c1b5c58e241f4a281dd14d2eefacb9063bf66b1a7c57f4
mpfr-4.1.0-rc2.tar.gz
8ff1252a89de8fc33dc8c147f6e56ee7e971787d5ce4291c9e0f0605ac51b384
mpfr-4.1.0-rc2.tar.xz
41538322aa5fb54cc4c412e80864fab47eba226f9dac362547bd8e5ff9b4bbb3
mpfr-4.1.0-rc2.zip
The signatures:
https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0-rc2.tar.xz.asc
https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0-rc2.tar.bz2.asc
https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0-rc2.tar.gz.asc
https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0-rc2.zip.asc
Each tarball is signed by Vincent Lefèvre. This can be verified using
the DSA key ID 980C197698C3739D; this key can be retrieved with:
gpg --recv-keys 980C197698C3739D
or by downloading it from .
The key fingerprint is:
07F3 DBBE CC1A 3960 5078 094D 980C 1976 98C3 739D
The signatures can be verified with: gpg --verify
You should check that the key fingerprint matches.
Changes from versions 4.0.* to version 4.1.0:
- The "épinards à la crème" release.
- Binary compatible with MPFR 4.0.*, though some minor changes in the
behavior of the formatted output functions may be visible, regarded
as underspecified behavior or bug fixes (see below).
- New --enable-formally-proven-code configure option, to use (when available)
formally proven code.
- Improved __GMP_CC and __GMP_CFLAGS retrieval (in particular for MS Windows).
- Option -pedantic is now always removed from __GMP_CFLAGS (see INSTALL).
- Changed __float128 to the type _Float128 specified in ISO/IEC TS 18661.
__float128 is used as a fallback if _Float128 is not supported.
- New function mpfr_get_str_ndigits about conversion to a string of digits.
- New function mpfr_dot for the dot product (incomplete, experimental).
- New functions mpfr_get_decimal128 and mpfr_set_decimal128 (available only
when MPFR has been built with decimal float support).
- New function mpfr_cmpabs_ui.
- New function mpfr_total_order_p for the IEEE 754 totalOrder predicate.
- The mpfr_out_str function now accepts bases from -2 to -36, in order to
follow mpfr_get_str and GMP's mpf_out_str functions (these cases gave an
assertion failure, as with other invalid bases).
- Shared caches: cleanup; really detect lock failures (abort in this case).
- The behavior of the formatted output functions (mpfr_printf, etc.) with
an empty precision field has improved: trailing zeros are kept in a way
similar to the formatted output functions from C.
- Improved mpfr_add and mpfr_sub when all operands have a precision equal to
twice the number of bits per word, e.g., 128 bits on a 64-bit platform.
- Optimized the tuning parameters for various architectures.
- Improved test coverage to 98.6% of code for x86_64.
- Bug fixes.
- MPFR manual: corrected/completed the mpfr_get_str description in order to
follow the historical behavior and GMP's mpf_get_str function.
- New: optional "make check-exported-symbols", mainly for the MPFR developers
and binary distributions, to check that MPFR does not define symbols with a
GMP reserved prefix (experimental).
- Mini-gmp support: replaced --enable-mini-gmp configure option by
--with-mini-gmp (still experimental, read doc/mini-gmp).
- A GCC bug on Sparc (present at least in old GCC 4.5.3 and 5.5.0 versions),
which made several tests fail when TLS was enabled, is now avoided in the
tests. The MPFR library itself was not affected and normal code using the
MPFR library should not be affected either. Users and distributions that
disabled TLS just because of the test failures can safely re-enable it.
Please send success and failure reports with "./config.guess" output
to .
If no problems are found, GNU MPFR 4.1.0 should be released
around 2020-07-10.
Regards,
--
Vincent Lefèvre - Web:
Re: [OMPD] Questions on per-process functions and related data types.
On Wed, Jul 01, 2020 at 10:50:44PM -0400, y2s1982 . via Gcc wrote:
> per-process functions defined in 5.5.2.
> I have some questions on defining or at least using some of the data types.
The standard makes those intentionally not defined, it is up to the
implementation to put in there whatever is needed/useful. That is the whole
idea behind handles, which are pointer to these, but it is not ok for the
debugger to make assumptions on what exactly it points to
(similarly how e.g. with the context handles which are again pointers to
some data in the debugger and OMPD shouldn't assume anything, just pass it
around).
> --- a/libgomp/libgompd.h
> +++ b/libgomp/libgompd.h
> @@ -29,9 +29,13 @@
> #ifndef LIBGOMPD_H
> #define LIBGOMPD_H 1
>
> +#include "omp-tools.h"
> +
> #define ompd_stringify(x) ompd_str2(x)
> #define ompd_str2(x) #x
>
> #define OMPD_VERSION 201811
>
> +extern ompd_callbacks_t gompd_callbacks;
> +
Confused, weren't these changes already in the previous patch?
(and other hunks too).
> #endif /* LIBGOMPD_H */
> diff --git a/libgomp/ompd-lib.c b/libgomp/ompd-lib.c
> index f0ae9e85a7e..d5350e1045c 100644
> --- a/libgomp/ompd-lib.c
> +++ b/libgomp/ompd-lib.c
> @@ -29,6 +29,9 @@
> #include "omp-tools.h"
> #include "libgompd.h"
>
> +ompd_callbacks_t gompd_callbacks;
> +static int ompd_initialized = 0;
> +
> ompd_rc_t
> ompd_get_api_version (ompd_word_t *version)
> {
> @@ -47,15 +50,24 @@ ompd_get_version_string (const char **string)
> ompd_rc_t
> ompd_initialize (ompd_word_t api_version, const ompd_callbacks_t *callbacks)
> {
> - static int ompd_initialized = 0;
> + if (!callbacks)
> +return ompd_rc_bad_input;
>
>if (ompd_initialized)
> return ompd_rc_error;
>
> + gompd_callbacks = *callbacks;
> +
>(void) api_version;
> - (void) callbacks;
>
>ompd_initialized = 1;
>
>return ompd_rc_ok;
> }
> +
> +ompd_rc_t
> +ompd_finalize (void)
> +{
> + ompd_initialized = 0;
> + return ompd_rc_ok;
> +}
> diff --git a/libgomp/ompd-proc.c b/libgomp/ompd-proc.c
> new file mode 100644
> index 000..6a9c827e327
> --- /dev/null
> +++ b/libgomp/ompd-proc.c
> @@ -0,0 +1,95 @@
> +/* Copyright (C) 2020 Free Software Foundation, Inc.
> + Contributed by Yoosuk Sim .
> +
> + This file is part of the GNU Offloading and Multi Processing Library
> + (libgomp).
> +
> + Libgomp is free software; you can redistribute it and/or modify it
> + under the terms of the GNU General Public License as published by
> + the Free Software Foundation; either version 3, or (at your option)
> + any later version.
> +
> + Libgomp is distributed in the hope that it will be useful, but WITHOUT ANY
> + WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS
> + FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + more details.
> +
> + Under Section 7 of GPL version 3, you are granted additional
> + permissions described in the GCC Runtime Library Exception, version
> + 3.1, as published by the Free Software Foundation.
> +
> + You should have received a copy of the GNU General Public License and
> + a copy of the GCC Runtime Library Exception along with this program;
> + see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
> +
Re: [OMPD] Questions on per-process functions and related data types.
Hello,
Thank you for the detailed reply. I have some questions.
On Thu, Jul 2, 2020 at 8:47 AM Jakub Jelinek wrote:
> On Wed, Jul 01, 2020 at 10:50:44PM -0400, y2s1982 . via Gcc wrote:
> > per-process functions defined in 5.5.2.
> > I have some questions on defining or at least using some of the data
> types.
>
> The standard makes those intentionally not defined, it is up to the
> implementation to put in there whatever is needed/useful. That is the
> whole
> idea behind handles, which are pointer to these, but it is not ok for the
> debugger to make assumptions on what exactly it points to
> (similarly how e.g. with the context handles which are again pointers to
> some data in the debugger and OMPD shouldn't assume anything, just pass it
> around).
>
I thought I understood this part, but I just need a little more nudge. I
get that standard left it
to the discretion to the implementation, and I assumed we would be the ones
to define
them. Is it okay to define the handle? Also, is the context only stored in
the OMPD and
is only used when passed back to the debugger so that debugger understands
the context
to the information OMPD gave back to it? Does that mean any of the
functions I use should
not try to get information from it? Does this also mean I shouldn't free
up the context pointers
when releasing the handle as the information is handled by the debugger?
>
> > --- a/libgomp/libgompd.h
> > +++ b/libgomp/libgompd.h
> > @@ -29,9 +29,13 @@
> > #ifndef LIBGOMPD_H
> > #define LIBGOMPD_H 1
> >
> > +#include "omp-tools.h"
> > +
> > #define ompd_stringify(x) ompd_str2(x)
> > #define ompd_str2(x) #x
> >
> > #define OMPD_VERSION 201811
> >
> > +extern ompd_callbacks_t gompd_callbacks;
> > +
>
> Confused, weren't these changes already in the previous patch?
> (and other hunks too).
>
I didn't get any reply and wasn't sure if the patch was approved.
I also needed the gompd_callbacks to define the functions.
I then thought they were small enough and similar enough changes to
combine into a single patch. Should I keep them separated?
> > #endif /* LIBGOMPD_H */
> > diff --git a/libgomp/ompd-lib.c b/libgomp/ompd-lib.c
> > index f0ae9e85a7e..d5350e1045c 100644
> > --- a/libgomp/ompd-lib.c
> > +++ b/libgomp/ompd-lib.c
> > @@ -29,6 +29,9 @@
> > #include "omp-tools.h"
> > #include "libgompd.h"
> >
> > +ompd_callbacks_t gompd_callbacks;
> > +static int ompd_initialized = 0;
> > +
> > ompd_rc_t
> > ompd_get_api_version (ompd_word_t *version)
> > {
> > @@ -47,15 +50,24 @@ ompd_get_version_string (const char **string)
> > ompd_rc_t
> > ompd_initialize (ompd_word_t api_version, const ompd_callbacks_t
> *callbacks)
> > {
> > - static int ompd_initialized = 0;
> > + if (!callbacks)
> > +return ompd_rc_bad_input;
> >
> >if (ompd_initialized)
> > return ompd_rc_error;
> >
> > + gompd_callbacks = *callbacks;
> > +
> >(void) api_version;
> > - (void) callbacks;
> >
> >ompd_initialized = 1;
> >
> >return ompd_rc_ok;
> > }
> > +
> > +ompd_rc_t
> > +ompd_finalize (void)
> > +{
> > + ompd_initialized = 0;
> > + return ompd_rc_ok;
> > +}
> > diff --git a/libgomp/ompd-proc.c b/libgomp/ompd-proc.c
> > new file mode 100644
> > index 000..6a9c827e327
> > --- /dev/null
> > +++ b/libgomp/ompd-proc.c
> > @@ -0,0 +1,95 @@
> > +/* Copyright (C) 2020 Free Software Foundation, Inc.
> > + Contributed by Yoosuk Sim .
> > +
> > + This file is part of the GNU Offloading and Multi Processing Library
> > + (libgomp).
> > +
> > + Libgomp is free software; you can redistribute it and/or modify it
> > + under the terms of the GNU General Public License as published by
> > + the Free Software Foundation; either version 3, or (at your option)
> > + any later version.
> > +
> > + Libgomp is distributed in the hope that it will be useful, but
> WITHOUT ANY
> > + WARRANTY; without even the implied warranty of MERCHANTABILITY or
> FITNESS
> > + FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> > + more details.
> > +
> > + Under Section 7 of GPL version 3, you are granted additional
> > + permissions described in the GCC Runtime Library Exception, version
> > + 3.1, as published by the Free Software Foundation.
> > +
> > + You should have received a copy of the GNU General Public License and
> > + a copy of the GCC Runtime Library Exception along with this program;
> > + see the files COPYING3 and COPYING.RUNTIME respectively. If not, see
> > +
Re: [OMPD] Questions on per-process functions and related data types.
On Thu, Jul 02, 2020 at 10:57:11AM -0400, y2s1982 . wrote: > > On Wed, Jul 01, 2020 at 10:50:44PM -0400, y2s1982 . via Gcc wrote: > > > per-process functions defined in 5.5.2. > > > I have some questions on defining or at least using some of the data > > types. > > > > The standard makes those intentionally not defined, it is up to the > > implementation to put in there whatever is needed/useful. That is the > > whole > > idea behind handles, which are pointer to these, but it is not ok for the > > debugger to make assumptions on what exactly it points to > > (similarly how e.g. with the context handles which are again pointers to > > some data in the debugger and OMPD shouldn't assume anything, just pass it > > around). > > > > I thought I understood this part, but I just need a little more nudge. I > get that standard left it > to the discretion to the implementation, and I assumed we would be the ones > to define > them. Is it okay to define the handle? Also, is the context only stored in Yes. But only in libgompd.h, not in omp-tools.h. I.e. anything outside of libgompd.so shouldn't have a way to find out what it is and how to access it. Similarly, the ompd_address_space_context_t is something that is owned by the debugger, OMPD should have no business to look at it, only pass the pointer to the callbacks. The objects allocated by OMPD that are OMPD-internal of course may not be freed by anything but OMPD itself, and similarly something that is private to the debugger and OMPD doesn't know the size/what it contains shouldn't be freed by OMPD. > I didn't get any reply and wasn't sure if the patch was approved. The latest version was ok. > I also needed the gompd_callbacks to define the functions. > I then thought they were small enough and similar enough changes to > combine into a single patch. Should I keep them separated? Yes, commit the first patch and then send diffs against that. > Okay. I thought of having just a single return statement per function, but > I will change them. No need to have a single return, you can have as many as you want in C, it is up to the compiler to compile it. > I do have a question: as handle is considered the output of the function, > should > I still assume it is not NULL when passed in? Depends on what the standard says. If it is unspecified behavior what happens if it is NULL, then you can assume it is non-NULL and don't even need to check for NULL, if it says what should happen when NULL is passed, you should follow that. > > > + if (ret == ompd_rc_ok && (*handle).context) > > > +ret = gompd_callbacks.free_memory ((*handle).context); > > > > > +#define OMPD_TYPES_VERSION 20180906 /* MMDD Format */ > > > > Where does the 20180906 come from? > > > > Much of the ompd-types.h comes from > https://github.com/OpenMP/sources/blob/master/include/ompd-types.h. > OMPD_TYPES_VERSION was a part of it. Should I change the value as I > added more to this, or should I separate the custom definition to a > separate file > to keep the version consistent with OpenMP? Ok, keep it as is and I'll ask the author what is the reason for that. > Also, most of the formatting issues in the file were the result of the > direct > copy/paste from their code. While I did change the 8 spaces to a tab > character, > it seems there are more to fix. I will fix them. https://github.com/OpenMP/sources/ uses different formatting conventions, as I said earlier, it is ok and often required to use the same macros/function prototypes etc., but the formatting and comments should be in the GNU style. Jakub
Re: An problematic interaction between a call created by gimple_build_call and inlining
Martin, What about immediate dominators? Thanks, Gary From: Martin Jambor Sent: Wednesday, July 1, 2020 3:40 PM To: Gary Oblock ; Richard Biener Cc: gcc@gcc.gnu.org Subject: Re: An problematic interaction between a call created by gimple_build_call and inlining [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please be mindful of safe email handling and proprietary information protection practices.] Hi, On Wed, Jul 01 2020, Gary Oblock via Gcc wrote: > Thank you Richard. > > I feel a bit dumb because I'm well aware of the GCC philosophy to have > any new code produced update the state. Of course I didn't know the > commands to do this for the call graph (which I really appreciate you giving.) > > However, the real reason I'm sending a reply is this. Are there any surprising > cases in IPA where GCC violates its philosophy and actually regenerates the > information? if by "the information" you specifically mean call graph edges then no. (Regular) IPA optimizations are designed to also work when doing link time optimization (LTO) which means that unless they specifically load the (gimple) bodies of some selected functions, the bodies are not available to them. They only operate on the call graph and information they collected when generating summaries. Because gimple body is not available, call graph edges cannot be regenerated from it. In fact, when a call is redirected to a different/specialized function, at IPA time it is only recored in the call graph by redirecting the corresponding edge and the call statement is modified only at the end of IPA phase (in LTRANS in LTO-speak). This is necessary even when not using LTO because until specialized nodes get their own body, they share it with the node from which they were cloned. That means that several call graph edges, which do not share caller and may not even share the callee, refer to the same gimple statement - so the decl in the statement is actually meaningless and the edge encodes the important information. Martin
Re: How to forbid register allocator to overlap bewteen DEST and SOURCE
On Wed, Jul 1, 2020 at 8:40 PM wrote: > GCC seems to overlap register bewteen DEST and SOURCE in different > machine mode, > Is there any target hooks to control this feature ? > I use ‘&’ to forbid register allocator to > overlap bewteen DEST and SOURCE, > but there are some redundancy instructions in the result code :( & is the correct solution in general. Presumably this is about your draft v0.7.1 vector port. This port uses an unspec in every pattern. This limits the compiler's ability to optimize code. You might get better results if you eliminated as many of the unspecs as you can. You might want to check TARGET_MODES_TIEABLE_P though this is mostly about casts and moves not register allocation. Jim
gcc-8-20200702 is now available
Snapshot gcc-8-20200702 is now available on https://gcc.gnu.org/pub/gcc/snapshots/8-20200702/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-8 revision 10b028c2813f683a8ebab7d36c9d0d05b49a710b You'll find: gcc-8-20200702.tar.xzComplete GCC SHA256=d273724884167c123ec41a9813125e4b69651134cc2d247397cba0a5815d8bae SHA1=64f6357c216b2dedb3fcd147bd78bff61db054f8 Diffs from 8-20200625 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.
Re: [OMPD] Questions on per-process functions and related data types.
On Thu, Jul 2, 2020 at 11:12 AM Jakub Jelinek wrote: > On Thu, Jul 02, 2020 at 10:57:11AM -0400, y2s1982 . wrote: > > > On Wed, Jul 01, 2020 at 10:50:44PM -0400, y2s1982 . via Gcc wrote: > > > > per-process functions defined in 5.5.2. > > > > I have some questions on defining or at least using some of the data > > > types. > > > > > > The standard makes those intentionally not defined, it is up to the > > > implementation to put in there whatever is needed/useful. That is the > > > whole > > > idea behind handles, which are pointer to these, but it is not ok for > the > > > debugger to make assumptions on what exactly it points to > > > (similarly how e.g. with the context handles which are again pointers > to > > > some data in the debugger and OMPD shouldn't assume anything, just > pass it > > > around). > > > > > > > I thought I understood this part, but I just need a little more nudge. I > > get that standard left it > > to the discretion to the implementation, and I assumed we would be the > ones > > to define > > them. Is it okay to define the handle? Also, is the context only stored > in > > Yes. But only in libgompd.h, not in omp-tools.h. I.e. anything outside of > libgompd.so shouldn't have a way to find out what it is and how to access > it. > Similarly, the ompd_address_space_context_t is something that is owned by > the debugger, OMPD should have no business to look at it, only pass the > pointer to the callbacks. > The objects allocated by OMPD that are OMPD-internal of course may not be > freed by anything but OMPD itself, and similarly something that is private > to the debugger and OMPD doesn't know the size/what it contains shouldn't > be > freed by OMPD. > This is giving me more clarity on what I have to do. At the moment, I am storing the information in the handle. I do have one problem: in 5.5.2.1 ( https://www.openmp.org/spec-html/5.0/openmpsu214.html#x270-18090005.5.2) it states that the call may verify the version compatibility using the context. How should I handle this? The version compatibility is something I am also struggling with. I don't know if the higher version is backward compat with all earlier versions or like automake, where each version may or maynot be compatible with the earlier versions. > > I do have a question: as handle is considered the output of the function, > > should > > I still assume it is not NULL when passed in? > > Depends on what the standard says. If it is unspecified behavior what > happens if it is NULL, then you can assume it is non-NULL and don't even > need to check for NULL, if it says what should happen when NULL is passed, > you should follow that. > I realized I was being dumb: if no address to the pointer is passed in, there's no place to write the output. The document also states that the tool owns the address space, so I assume the tool created the handle before passing in the address to its own pointer. I will check for NULL. Cheers, Tony Sim
[GSOC] Automatic Parallel Compilation Viability, Report 1
Hi, I am attaching here the first report of the "Automatic Parallel Viability" project. Please feel free to suggest improvements to the project. The content below is presented in markdown format, and you can easily convert it to PDF with pandoc if you feel it uncomfortable to read in current format. ``` # Automatic Parallel Compilation Viability: First Report ## Complete Tasks There were two tasks scheduled to be complete in this stage: 1. Update the driver to pass a hidden `-fsplit-outputs` to the compiler, writting down the path to each assembler file generated by the compiler. 2. Update the compiler to partition the program, and fork on each partition, generating one asm file per partition. The compiler should compile some programs correctly at this point. Both of these tasks were completed at this point, as we have a version of GCC that bootstraps and have a small speedup when compiling insn-emit.c in parallel (with --enable-checking, 42s sequential w/o partitioning vs. 36s parallel). ## First Implementation The first working implementation consists of two parts: - A partitioner designed to handle the Compilation Unit as if it only have part of the program information, as opposed as the WPA partitioner that have the entire program callgraph. This imposes some restriction on us about our partitioner, that is: 1. Static functions that calls eachother are mapped to the same partition to avoid renaming and promotion to globals. 2. Functions that have references to a same global variable are mapped into the same partition to avoid multiple definitions of this partition. 3. Functions which address are taken partitioned together with whoever took the address and with calls that has the possibility to receive the address as argument. 4. COMDATs should be in the same partition. - A way to apply a `ltrans_partition` without dumping the partition to disk and reloading it. This is done by looking into the partitioner generated encoder and releasing information about functions that are not in the partition by releasing function bodies, dominator tree, entries at clone tree, and setting the variables accordingly. This implementation lead to very unbalanced partitions, as it generate one really big partition and several very small partitions. However, the partitioner showed to be very fast in practice, with preliminary complexity of O(|E| * log\*(|V|)), which is approximately linear on the number of edges of the graph, as log\*(2^64) = 5. Sure the worst case scenario where the callgraph is the complete graph implies |E| = |V|\*(|V| - 1)/2, but that looks very synthetic to a input program. ## Ongoing Implementation This implementation is still work on progress, but has showed significant improvements when compared to the first implementation. First we relax the condition 1. by not merging calls that were inlined, and relax condition 2. by not merging functions that references non-static global variables. We managed to get this version to bootstrap by commenting some assertions at ipa-cp optimization pass, probably because `node->local` is incorrectly set in some cases, and calling `remove_unreachable_nodes` after applying the partition to the callgraph, but marking nodes inside the partition to be `force_output` before entering that function so there is no risk of being removed incorrectly, and unseting `force_output` afterwards for nodes that wasn't set beforehand. This methodology yielded a speedup of 2x on a Quad Core Intel Core-i7 8565U CPU when compiling insn-emit.c (24.509s parallel vs. 45.909s sequential), but no speedup at all when compiling gimple-match.c, this file looks really problematic on current methodology because it has 3 entry points and is stuffed with static functions. We are also exploring the possibility of promoting non-inlined static functions to globals in some cases where it might improve compilation performance, although it may slowdown the produced binary in some architectures, therefore completely removing restriction 1. Our results with that restriction relaxed on gimple-match.c showed a 2.12x improvement over serial compilation (36.184s parallel vs. 1m17s sequential). ## Conclusions So far the work has shows to be promising. Compilation of insn-emit.c is greatly improved with 2x speedup although no improvements to gimple-match.c was observed without relaxing condition 1. Once this new partitioner bootstrap, we will proceed to implementing support for the GNU Jobserver. ```
Questions regarding control flow during IPA passes
At IPA time I'm creating GIMPLE statements. I've noticed during dumps that gotos and labels don't seem to exist. In fact when I tried introducing them, at least the gotos, failed. I assume that at this point in compilation GCC relies on the control flow graph (which I'm updating as I create new BBs) so I actually shouldn't create them? Furthermore, I assume I should be setting the "gotos" in the condition statement to NULL? Thanks, Gary Oblock Ampere Computing Santa Clara, California CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to Ampere Computing or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. Any review, copying, or distribution of this email (or any attachments thereto) is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.
