Re: [PATCH] PR105647 Update pr105169* so it does not fail on powerpc64le

On Thu, 2022-05-19 at 06:34 +, Richard Biener wrote: > On Wed, 18 May 2022, Giuliano Belinassi wrote: > > > On powerpc64le, the tests related to pr105169 failed because the > > .localentry was not on a power of two address due to the extra nop > > instruction taking one byte and thus moving

Re: [PATCH v2] PR105169 Fix references to discarded sections

On Mon, 2022-05-09 at 13:39 +0200, Richard Biener wrote: > On Sat, 7 May 2022, Giuliano Belinassi wrote: > > > When -fpatchable-function-entry= is enabled, certain C++ codes > > fails to > > link because of generated references to discarded sections in > > __patchable_function_entry section. This

[PATCH v2] PR105169 Fix references to discarded sections

When -fpatchable-function-entry= is enabled, certain C++ codes fails to link because of generated references to discarded sections in __patchable_function_entry section. This commit fixes this problem by puting those references in a COMDAT section. On the previous patch, GCC fails to compile with

Re: [PATCH] PR105169 Fix references to discarded sections

Hi, On Tue, 2022-04-19 at 10:11 +0200, Richard Biener wrote: > On Thu, 14 Apr 2022, Giuliano Belinassi wrote: > > > When -fpatchable-function-entry= is enabled, certain C++ codes > > fails to > > link because of generated references to discarded sections in > > __patchable_function_entry

[PATCH] PR105169 Fix references to discarded sections

When -fpatchable-function-entry= is enabled, certain C++ codes fails to link because of generated references to discarded sections in __patchable_function_entry section. This commit fixes this problem by puting those references in a COMDAT section. Boostrapped and regtested on x86_64 linux. OK

Re: [PATCH v3] Do not abort compilation when dump file is /dev/*

On Sun, 2021-11-21 at 00:47 -0300, Alexandre Oliva wrote: > Hello, Giuliano, thanks for turning my suggestion into a patch! > > On Nov 19, 2021, Richard Biener wrote: > > > > +/* { dg-options "-fdump-ipa-clones -o /dev/null" } */ > > May I suggest actually checking that the ipa-clones dump

[PATCH v3] Do not abort compilation when dump file is /dev/*

The `configure` scripts generated with autoconf often tests compiler features by setting output to `/dev/null`, which then sets the dump folder as being /dev/* and the compilation halts with an error because GCC cannot create files in /dev/. This is a problem when configure is testing for compiler

[PATCH v2] Do not abort compilation when dump file is /dev/*

The `configure` scripts generated with autoconf often tests compiler features by setting output to `/dev/null`, which then sets the dump folder as being /dev/* and the compilation halts with an error because GCC cannot create files in /dev/. This is a problem when configure is testing for compiler

Re: [PATCH] Do not abort compilation when dump file is /dev/*

On Thu, 2021-11-18 at 10:43 +0100, Richard Biener wrote: > On Tue, 16 Nov 2021, Giuliano Belinassi wrote: > > > The `configure` scripts generated with autoconf often tests > > compiler > > features by setting output to `/dev/null`, which then sets the dump > > folder as being /dev/* and the

[PATCH] Do not abort compilation when dump file is /dev/*

The `configure` scripts generated with autoconf often tests compiler features by setting output to `/dev/null`, which then sets the dump folder as being /dev/* and the compilation halts with an error because GCC cannot create files in /dev/. This is a problem when configure is testing for compiler

Re: [PATCH] Fix PR 100944 - Array boundary misscalculation

Hi, I will give an quick answer to this mail. I will analyze carefully what richi said when I have more time available. On Mon, 2021-06-14 at 15:55 -0600, Martin Sebor wrote: > On 6/13/21 11:00 AM, Giuliano Belinassi wrote: > > This patch proposes a fix to PR 100944 by improving the array > >

[PATCH] Fix PR 100944 - Array boundary misscalculation

This patch proposes a fix to PR 100944 by improving the array boundary computation when the flexible array has no clear constructor: if no constructor were found in the input code, we compute the size of the array as: offset(array begin) - offset(next element in RECORD_TYPE) If no next element

Re: [PATCH] Try LTO partial linking. (Was: Speed of compiling gimple-match.c)

Hi, all. Please CC me when I am mentioned into a mail. On Thu, 2021-05-20 at 15:16 +0200, Richard Biener via Gcc wrote: > On Thu, May 20, 2021 at 3:06 PM Martin Liška wrote: > > > > On 5/20/21 2:54 PM, Richard Biener wrote: > > > So why did you go from applying this per-file to multiple files?

Re: [PATCH 2/6] Implement a new partitioner for parallel compilation

Hi, Honza. Again, thank you for your detailed review! On 08/27, Jan Hubicka wrote: > > When using the LTO infrastructure to compile files in parallel, we > > can't simply use any of the LTO partitioner, once extra dependency > > analysis is required to ensure that some nodes are correctly > >

Re: [PATCH 3/6] Implement fork-based parallelism engine

Hi, Honza. Thank you for your detailed review! On 08/27, Jan Hubicka wrote: > > diff --git a/gcc/cgraph.c b/gcc/cgraph.c > > index c0b45795059..22405098dc5 100644 > > --- a/gcc/cgraph.c > > +++ b/gcc/cgraph.c > > @@ -226,6 +226,22 @@ cgraph_node::delete_function_version_by_decl (tree > > decl)

Re: [PATCH 0/6] Parallelize Intra-Procedural Optimizations using the LTO Engine.

Ho, Josh. On 08/24, Josh Triplett wrote: > On Sat, Aug 22, 2020 at 06:04:48PM -0300, Giuliano Belinassi wrote: > > Hi, Josh > > > > On 08/21, Josh Triplett wrote: > > > On Thu, Aug 20, 2020 at 07:00:13PM -0300, Giuliano Belinassi wrote: > > > > This patch series add a new flag "-fparallel-jobs="

Re: [PATCH 1/6] Modify gcc driver for parallel compilation

Hi, Richi. On 08/24, Richard Biener wrote: > On Fri, Aug 21, 2020 at 12:00 AM Giuliano Belinassi > wrote: > > > > Update the driver for parallel compilation. This process work as > > follows: > > > > When calling gcc, the driver will check if the flag > > "-fparallel-jobs" was provided by the

Re: [PATCH 0/6] Parallelize Intra-Procedural Optimizations using the LTO Engine.

Hi, Richi. On 08/24, Richard Biener wrote: > On Fri, Aug 21, 2020 at 12:00 AM Giuliano Belinassi > wrote: > > > > This patch series add a new flag "-fparallel-jobs=" to control if the > > compiler should try to compile the current file in parallel. > > > > There are three modes which is

Re: [PATCH 0/6] Parallelize Intra-Procedural Optimizations using the LTO Engine.

Hi, Josh On 08/21, Josh Triplett wrote: > On Thu, Aug 20, 2020 at 07:00:13PM -0300, Giuliano Belinassi wrote: > > This patch series add a new flag "-fparallel-jobs=" to control if the > > compiler should try to compile the current file in parallel. > [...] > > Bootstrapped and Regtested on Linux

[PATCH 4/6] Add `+' for Jobserver Integration

GNU Make expects that a `+' token is present on the beggining of the rule command if it wants to interact with the Jobserver [1]. This commit add such token for the Makefiles in GCC. [1] https://www.gnu.org/software/make/manual/html_node/POSIX-Jobserver.html#POSIX-Jobserver gcc/ChangeLog:

[PATCH 2/6] Implement a new partitioner for parallel compilation

When using the LTO infrastructure to compile files in parallel, we can't simply use any of the LTO partitioner, once extra dependency analysis is required to ensure that some nodes are correctly partitioned together. Therefore, here we implement a new partitioner called "lto_merge_comdat_map"

[PATCH 3/6] Implement fork-based parallelism engine

This patch belongs to the "Parallelize GCC with Processes" series. Here, we implement the parallelism by forking the compiler into multiple processes after what would be the LTO LTRANS stage, partitioning the callgraph into several partitions, as implemented in "maybe_compile_in_parallel". From a

[PATCH 5/6] Add invoke documentation

Add documentation about how to invoke GCC in order to use parallel compilation. gcc/ChangeLog: 20-08-2020 Giuliano Belinassi * doc/invoke.texi: Document -fparallel-jobs=. --- gcc/doc/invoke.texi | 32 +++- 1 file changed, 31 insertions(+), 1 deletion(-)

[PATCH 6/6] New tests for parallel compilation feature

Adds new tests for testing the parallel compilation engine. They mainly test issues with regard to symbol promotion clash and incorrect early assembler output. 2020-08-20 Giuliano Belinassi * gcc.dg/parallel-early-constant.c: New test. * gcc.dg/parallel-static-1.c: New test.

[PATCH 1/6] Modify gcc driver for parallel compilation

Update the driver for parallel compilation. This process work as follows: When calling gcc, the driver will check if the flag "-fparallel-jobs" was provided by the user. If yes, then we will check what is the desired output, and if it can be parallelized. There are the following cases, which is

[PATCH 0/6] Parallelize Intra-Procedural Optimizations using the LTO Engine.

This patch series add a new flag "-fparallel-jobs=" to control if the compiler should try to compile the current file in parallel. There are three modes which is supported by now: 1. -fparallel-jobs=: Try to compile the file using a maximum of N jobs. 2. -fparallel-jobs=jobserver: Check if

[PATCH] Refactor `execute` from gcc.c

Hi, After having so much trouble working on the `execute' function inside gcc.c, I decided to refactor it so that it could be more digestible. Since I am using it on my branch, I am submitting this patch for "battlefield" testing. Bootstrapped and ran the testsuite on Linux x86_64. -

Re: [PATCH] Refactor tree-vrp.c

Hi. On 05/11, Richard Biener wrote: > On Fri, May 8, 2020 at 7:11 PM Jeff Law via Gcc-patches > wrote: > > > > On Fri, 2020-05-08 at 13:06 -0300, Giuliano Belinassi via Gcc-patches wrote: > > > Hi, > > > > > > This patch Refactors tree-v

[PATCH] Refactor tree-vrp.c

Hi, This patch Refactors tree-vrp.c to eliminate all global variables except 'x_vrp_values', which will require that 'thread_outgoing_edges' to accept an extra argument and pass it to the 'simplify' callback. It also removes every access to 'cfun', retrieving the function being compiled from the

Re: [PATCH v3] [Stage1] Refactor tree-ssa-operands.c

Hi, This patch Refactors tree-ssa-operands.c by wrapping the global variables into a class, and also removes unused code. The difference between this version and v2 is: * Disable the copy of operands_scanner * remove void from empty arguments functions. gcc/ChangeLog: 2020-05-04 Giuliano

Re: [PATCHv2] [Stage1] Refactor tree-ssa-operands.c

Hi, Thank you for your quick review :) This patch refactors tree-ssa-operands.c by wrapping the global variables into a class, and also removes unused code. In this version, we now move struct function and gimple stmt arguments previously in the methods to the object constructor, so that we

[PATCH] [Stage1] Refactor tree-ssa-operands.c

This patch refactors tree-ssa-operands.c by wrapping the global variables into a class, and also removes unused code. Just sending this for when Stage1 is back again. I ran the testsuite and bootstraped in a x86_64 linux machine and found no issues. gcc/ChangeLog: 2020-04-22 Giuliano Belinassi