Hi,
This patch adds non-relative jump table support for 64bit rs6000. It
implements ASM_OUTPUT_ADDR_VEC_ELT and corresponding expansion of jump
table instruction for 64bit rs6000. We want to put non-relative jump
table in data.rel.ro section for rs6000. So I add a new target hook -
Hi Jim,
Thanks for your comments, We will try to solve the copyright problem and send
the patch as soon as possible.
Thanks,
Tao Wang
> -Original Message-
> From: Jim Wilson [mailto:j...@sifive.com]
> Sent: Tuesday, July 28, 2020 6:36 AM
> To: wangtao (CH)
> Cc:
Add testcase later is OK to me.
On Tue, Jul 28, 2020 at 6:55 AM Jim Wilson wrote:
>
> On Sun, Jul 19, 2020 at 7:04 PM cooper wrote:
> > Ping
> >
> > On 2020/7/13 下午4:15, cooper wrote:
> > > gcc/
> > > * config/riscv/riscv-opts.h (stack_protector_guard): New enum.
> > > *
ping?
On Sun, Jul 12, 2020 at 2:27 PM Paul Hua wrote:
>
> From 589dbe8a1c2397bfafefa4e84abe5ec6e6798928 Mon Sep 17 00:00:00 2001
> From: Andrew Pinski
> Date: Wed, 12 Feb 2020 11:42:57 +
> Subject: [PATCH] MIPS: Fix __builtin_longjmp (PR 64242)
>
> The problem here is mips has its own
This patch changes the Go frontend and the libgo runtime package to
pass only ptr and len to some runtime calls, rather than passing an
entire slice. This ports https://golang.org/cl/227163 to the Go
frontend. This is a step toward moving up to the go1.15rc1 release.
The original change says
This patch to the Go frontend changes package-scope "a = b; b = x" to
just set "a = x". This avoids requiring an init function to
initialize the variable. This can only be done if x is a static
initializer.
The go1.15rc1 runtime package relies on this optimization. The
package has a variable
Committed.
These FAILs for mmix showed up as regressions for me due to a
flaw in the btest-gcc.sh test-results-accounting: a bug was
recently fixed regarding the naming of dump-files so the names
are again correct. To wit, parts of the tests that were
UNRESOLVED, due to missing dump-files, and
Ping. ccing the aarch64 maintainers. If I don't get a response, I
will just commit this as obvious.
Jim
On Sun, Jul 12, 2020 at 4:52 PM Jim Wilson wrote:
>
> Noticed while reviewing the RISC-V -mstack-protector-guard docs. The, and
> could maybe be added as a separate patch.
> AArch64
On Sun, Jul 19, 2020 at 7:04 PM cooper wrote:
> Ping
>
> On 2020/7/13 下午4:15, cooper wrote:
> > gcc/
> > * config/riscv/riscv-opts.h (stack_protector_guard): New enum.
> > * config/riscv/riscv.c (riscv_option_override): Handle
> > the new options.
> > *
On Sun, Jul 26, 2020 at 11:40 PM wangtao (CH) wrote:
> This is the patch to support ZFINX of RISC-V, which option is like
> -march=rv32gc_zfinx. The ZFINX means f-registers in x-registers under RV-F
> and RV-D extension. For more details, please refer to
>
On Mon, 27 Jul 2020 14:41:14 +0200
Martin Jambor wrote:
> Hi,
>
> On Mon, Jul 27 2020, Richard Biener via Gcc-patches wrote:
> > On Sat, Jul 25, 2020 at 8:35 PM Sergei Trofimovich via Gcc-patches
> > wrote:
> >>
> >> From: Sergei Trofimovich
> >>
> >> In PR ipa/96291 the test contained an
From: Sergei Trofimovich
In PR ipa/96291 the test contained an SCC with one
unoptimized function. This tricked ipa-cp into NULL dereference.
has_undead_caller_from_outside_scc_p() did not take into account
that unoptimized funtions don't have IPA summary analysis. And
dereferenced NULL pointer
On Mon, Jul 27, 2020 at 09:53:31AM -0600, Martin Sebor via Gcc-patches wrote:
> Return a pointer P to a NUL-terminated string containing
> the sequence of bytes corresponding to the representation
> of the object referred to by SRC (or a subsequence of such
> bytes within it if SRC is a
The logic to figure out where a missing #include should be inserted uses
pointer equality to check filenames -- the routine even says so. But
cpplib makes no such guarantee. It happens to be true for input that it
preprocesses[* see line zero below], but is not true for source that has
On 7/27/20 12:54 PM, Martin Liška wrote:
On 7/27/20 5:53 PM, Martin Sebor wrote:
The tests I committed with the change didn't exercise any of
this so that's my bad. I'm still not sure I understand how
the problem with the incomplete type comes up (I haven't had
a chance to look into the recent
On Mon, Jul 27, 2020 at 12:14 PM H.J. Lu wrote:
>
> On Mon, Jul 27, 2020 at 9:11 AM Aaron Merey wrote:
> >
> > On Mon, Jul 27, 2020 at 11:32 AM H.J. Lu wrote:
> > >
> > > On Sat, Jul 25, 2020 at 9:01 AM H.J. Lu wrote:
> > > > This caused:
> > > >
> > > >
On Mon, Jul 27, 2020 at 9:11 AM Aaron Merey wrote:
>
> On Mon, Jul 27, 2020 at 11:32 AM H.J. Lu wrote:
> >
> > On Sat, Jul 25, 2020 at 9:01 AM H.J. Lu wrote:
> > > This caused:
> > >
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=26301
> > >
> >
> > It is quite normal to have debuginfod
On 7/27/20 5:53 PM, Martin Sebor wrote:
The tests I committed with the change didn't exercise any of
this so that's my bad. I'm still not sure I understand how
the problem with the incomplete type comes up (I haven't had
a chance to look into the recent updates on the bug yet) but
to retain the
Hello Jakub,
Thanks for the reply. I apparently need further clarification.
On Mon, Jul 27, 2020 at 12:36 PM Jakub Jelinek wrote:
> On Sat, Jul 25, 2020 at 11:03:27AM -0400, y2s1982 via Gcc-patches wrote:
> > This patch adds few helper functions aims to improve readability of
> > fetching
Zhongyunde writes:
> I reconsider the issue and update patch attached.
> Yes, If the kernel loop bb's information doesn't use in regrename, it
> also need not be collected to save compile time.
Thanks. The point about other callers was a good one though.
I think it would be OK to add a new
Hu Jiangping writes:
> Hi!
>
> This patch makes the -falign-foo=0 work as described in the
> documentation. Thanks for all the suggestions.
>
> v4: do changes for coding conventions
> v3: make change more readable and self-consistent
>
> Changelog:
> 2020-07-27 Hu Jiangping
>
> PR
This patch to the Go frontend scans all function literals for escape
analysis. We were scanning only function literals with closures, but
not all function literals have closures. The effect of this is a
missed optimization in some cases: we will allocate some variables on
the heap unnecessarily.
On Sat, Jul 25, 2020 at 11:03:27AM -0400, y2s1982 via Gcc-patches wrote:
> This patch adds few helper functions aims to improve readability of
> fetching addresses, sizes, and values. It also proposes a syntax for
> querying these information through the callback functions, similar to
> that of
On Mon, Jul 27, 2020 at 11:32 AM H.J. Lu wrote:
>
> On Sat, Jul 25, 2020 at 9:01 AM H.J. Lu wrote:
> > This caused:
> >
> > https://sourceware.org/bugzilla/show_bug.cgi?id=26301
> >
>
> It is quite normal to have debuginfod headers without libdebuginfod on
> multilib OSes. Restore AC_CHECK_LIB
On 7/27/20 6:32 AM, Martin Liška wrote:
Hey.
As mentioned in the PR, we should not create a string constant for a type
that is different from char_type_node. Looking at expr.c, I was inspired
and used 'TYPE_MAIN_VARIANT (chartype) == char_type_node' to verify that
underlying
type is a
On Sat, Jul 25, 2020 at 9:01 AM H.J. Lu wrote:
>
> On Fri, Jul 24, 2020 at 1:04 PM Aaron Merey via Gcc-patches
> wrote:
> >
> > On Tue, Jul 21, 2020 at 2:11 PM Aaron Merey wrote:
> > >
> > > On Tue, Jul 21, 2020 at 11:20 AM Tom Tromey wrote:
> > > >
> > > > Simon> Since it's debuginfo.m4 that
I apologize for the useless "From" address (and lack of "Reply-To"
address) on this patch series. My usual machine is down for
maintenance, so I ended up sending this from my laptop, which was
clearly not configured well enough for that. My bad. I won't do that
again.
Meantime, please
On Fri, 17 Jul 2020 13:16:11 +0200
Thomas Schwinge wrote:
> Hi Julian, Tobias!
>
> On 2020-07-15T12:28:42+0200, Thomas Schwinge
> wrote:
> > On 2020-07-14T13:43:37+0200, I wrote:
> >> On 2020-06-16T15:39:44-0700, Julian Brown
> >> wrote:
> >>> As mentioned in the blurb for the previous
Just a reminder this patch series exists and wants a review. :-)
Bill
On 7/27/20 9:13 AM, Bill Schmidt wrote:
From: Bill Schmidt
This is a slight reworking of the patches posted on June 17. I have
made a couple of improvements, but the general arrangement of the patches
is the same as
On Mon, Jul 27, 2020 at 12:29:11PM +0200, Richard Biener wrote:
> On Mon, Jul 27, 2020 at 11:45 AM Richard Sandiford
> wrote:
> >
> > Richard Biener writes:
> > > On Mon, Jul 27, 2020 at 11:09 AM Richard Sandiford
> > > wrote:
> > >>
> > >> Richard Biener via Gcc-patches writes:
> > >> > On
From: Bill Schmidt
2020-07-26 Bill Schmidt
* config/rs6000/rs6000-builtin.def: Add comments.
* config/rs6000/rs6000-call.c: Likewise.
---
gcc/config/rs6000/rs6000-builtin.def | 15 +++
gcc/config/rs6000/rs6000-call.c | 166 +++
2 files changed,
From: Bill Schmidt
2020-07-26 Bill Schmidt
* config/rs6000/rs6000-call.c (rs6000-builtins.h): New #include.
(rs6000_init_builtins): Call rs6000_autoinit_builtins.
---
gcc/config/rs6000/rs6000-call.c | 4
1 file changed, 4 insertions(+)
diff --git
From: Bill Schmidt
2020-07-26 Bill Schmidt
* config/rs6000/rs6000-builtin-new.def: Add ieee128-hw, dfp,
crypto, and htm builtins.
---
gcc/config/rs6000/rs6000-builtin-new.def | 217 +++
1 file changed, 217 insertions(+)
diff --git
From: Bill Schmidt
2020-07-26 Bill Schmidt
* config/rs6000/rs6000-builtin-new.def: Add power8-vector
builtins.
---
gcc/config/rs6000/rs6000-builtin-new.def | 417 +++
1 file changed, 417 insertions(+)
diff --git a/gcc/config/rs6000/rs6000-builtin-new.def
From: Bill Schmidt
2020-07-26 Bill Schmidt
* config/rs6000/rs6000-builtin-new.def: Add power9,
power9-vector, and power9-64 builtins.
---
gcc/config/rs6000/rs6000-builtin-new.def | 354 +++
1 file changed, 354 insertions(+)
diff --git
From: Bill Schmidt
2020-07-26 Bill Schmidt
* config/rs6000/rs6000-builtin-new.def: Add remaining AltiVec
builtins.
---
gcc/config/rs6000/rs6000-builtin-new.def | 843 +++
1 file changed, 843 insertions(+)
diff --git
From: Bill Schmidt
2020-07-26 Bill Schmidt
* config/rs6000/rs6000-gen-builtins.c (ovld_stanza): New struct.
(MAXOVLDSTANZAS): New defined constant.
(ovld_stanzas): New filescope variable.
(curr_ovld_stanza): Likewise.
(MAXOVLDS): New defined constant.
From: Bill Schmidt
2020-07-26 Bill Schmidt
* config.gcc (powerpc*-*-*): Add rs6000-builtins.o to extra_objs.
* config/rs6000/t-rs6000 (rs6000-gen-builtins.o): New target.
(rbtree.o): Likewise.
(rs6000-gen-builtins): Likewise.
(rs6000-builtins.c):
From: Bill Schmidt
2020-07-26 Bill Schmidt
* config/rs6000/rs6000-builtin-new.def: Add power7 and
power7-64 builtins.
---
gcc/config/rs6000/rs6000-builtin-new.def | 39
1 file changed, 39 insertions(+)
diff --git
From: Bill Schmidt
2020-07-26 Bill Schmidt
* config/rs6000/rs6000-gen-builtins.c (write_fntype): New
function.
(write_fntype_init): New stub function.
(write_init_bif_table): Likewise.
(write_init_ovld_table): New function.
(write_init_file):
From: Bill Schmidt
2020-07-26 Bill Schmidt
* config/rs6000/rs6000-builtin-new.def: Add VSX builtins.
---
gcc/config/rs6000/rs6000-builtin-new.def | 840 +++
1 file changed, 840 insertions(+)
diff --git a/gcc/config/rs6000/rs6000-builtin-new.def
From: Bill Schmidt
2020-07-26 Bill Schmidt
* config/rs6000/rs6000-gen-builtins.c (write_defines_file):
Implement.
---
gcc/config/rs6000/rs6000-gen-builtins.c | 4
1 file changed, 4 insertions(+)
diff --git a/gcc/config/rs6000/rs6000-gen-builtins.c
From: Bill Schmidt
2020-07-26 Bill Schmidt
* config/rs6000/rs6000-gen-builtins.c (complete_vector_type): New
function.
(complete_base_type): Likewise.
(construct_fntype_id): Likewise.
(parse_bif_entry): Call construct_fntype_id.
From: Bill Schmidt
2020-07-26 Bill Schmidt
* config/rs6000/rs6000-gen-builtins.c (write_init_bif_table):
Implement.
---
gcc/config/rs6000/rs6000-gen-builtins.c | 153
1 file changed, 153 insertions(+)
diff --git
From: Bill Schmidt
2020-07-26 Bill Schmidt
* config/rs6000/rs6000-gen-builtins.c
(write_autogenerated_header): New function.
(write_bif_enum): Likewise.
(write_ovld_enum): Likewise.
(write_decls): Likewise.
(write_extern_fntype): Likewise.
From: Bill Schmidt
2020-07-26 Bill Schmidt
* config/rs6000/rs6000-gen-builtins.c (parse_bif_attrs):
Implement.
---
gcc/config/rs6000/rs6000-gen-builtins.c | 86 +
1 file changed, 86 insertions(+)
diff --git a/gcc/config/rs6000/rs6000-gen-builtins.c
From: Bill Schmidt
2020-07-26 Bill Schmidt
* config/rs6000/rs6000-gen-builtins.c (typemap): New struct.
(TYPE_MAP_SIZE): New defined constant.
(type_map): New filescope variable; initialize.
(map_token_to_type_node): New function.
(write_type_node):
From: Bill Schmidt
2020-07-26 Bill Schmidt
* config/rs6000/rs6000-builtin-new.def: Add always, power5,
and power6 builtins.
---
gcc/config/rs6000/rs6000-builtin-new.def | 78
1 file changed, 78 insertions(+)
diff --git
From: Bill Schmidt
2020-07-26 Bill Schmidt
* config/rs6000/rs6000-gen-builtins.c (parse_args): New function.
(parse_prototype): Implement.
---
gcc/config/rs6000/rs6000-gen-builtins.c | 143
1 file changed, 143 insertions(+)
diff --git
From: Bill Schmidt
2020-07-26 Bill Schmidt
* config/rs6000/rs6000-gen-builtins.c (MININT): New defined
constant.
(exit_codes): New enum.
(consume_whitespace): New function.
(advance_line): Likewise.
(safe_inc_pos): Likewise.
From: Bill Schmidt
2020-07-26 Bill Schmidt
* config/rs6000/rs6000-gen-builtins.c (void_status): New enum.
(basetype): Likewise.
(typeinfo): New struct.
(handle_pointer): New function.
(match_basetype): New stub function.
From: Bill Schmidt
2020-07-26 Bill Schmidt
* config/rs6000/rbtree.c: New file.
* config/rs6000/rbtree.h: New file.
---
gcc/config/rs6000/rbtree.c | 233 +
gcc/config/rs6000/rbtree.h | 51
2 files changed, 284 insertions(+)
From: Bill Schmidt
This patch adds a tiny subset of the built-in and overload descriptions.
2020-07-26 Bill Schmidt
* config/rs6000/rs6000-builtin-new.def: New.
* config/rs6000/rs6000-overload.def: New.
---
gcc/config/rs6000/rs6000-builtin-new.def | 179
From: Bill Schmidt
2020-07-26 Bill Schmidt
* config/rs6000/rs6000-gen-builtins.c (match_basetype):
Implement.
---
gcc/config/rs6000/rs6000-gen-builtins.c | 49 +
1 file changed, 49 insertions(+)
diff --git a/gcc/config/rs6000/rs6000-gen-builtins.c
From: Bill Schmidt
2020-07-26 Bill Schmidt
* config/rs6000/rs6000-gen-builtins.c (rbtree.h): New #include.
(num_bifs): Likewise.
(num_ovld_stanzas): Likewise.
(num_ovlds): Likewise.
(exit_codes): Add more enum values.
(parse_codes): New enum.
From: Bill Schmidt
2020-07-26 Bill Schmidt
* config/rs6000/rs6000-gen-builtins.c (bif_file): New filescope
variable.
(ovld_file): Likewise.
(header_file): Likewise.
(init_file): Likewise.
(defines_file): Likewise.
(pgm_path): Likewise.
From: Bill Schmidt
2020-07-26 Bill Schmidt
* config/rs6000/rs6000-gen-builtins.c (restriction): New enum.
(typeinfo): Add restriction field.
(match_const_restriction): Implement.
---
gcc/config/rs6000/rs6000-gen-builtins.c | 136
1 file
From: Bill Schmidt
Add header commentary explaining the purpose of rs6000-gen-builtins.c,
along with an initial set of includes.
2020-07-26 Bill Schmidt
* config/rs6000/rs6000-gen-builtins.c: New.
---
gcc/config/rs6000/rs6000-gen-builtins.c | 141
1 file
From: Bill Schmidt
2020-07-26 Bill Schmidt
* config/rs6000/rs6000-gen-builtins.c (bif_stanza): New enum.
(curr_bif_stanza): Likewise.
(stanza_entry): New struct.
(stanza_map): New initialized filescope variable.
(enable_string): Likewise.
From: Bill Schmidt
This is a slight reworking of the patches posted on June 17. I have
made a couple of improvements, but the general arrangement of the patches
is the same as before. Two major things to call out:
- I've introduced a uniform set of parsing error codes to make it easier
to
On Mon, Jul 27, 2020 at 04:12:09PM +0200, Martin Liška wrote:
> On 7/27/20 3:16 PM, Jakub Jelinek wrote:
> > On Mon, Jul 27, 2020 at 02:32:15PM +0200, Martin Liška wrote:
> > > As mentioned in the PR, we should not create a string constant for a type
> > > that is different from char_type_node.
On 7/27/20 3:16 PM, Jakub Jelinek wrote:
On Mon, Jul 27, 2020 at 02:32:15PM +0200, Martin Liška wrote:
As mentioned in the PR, we should not create a string constant for a type
that is different from char_type_node. Looking at expr.c, I was inspired
and used 'TYPE_MAIN_VARIANT (chartype) ==
Hi,
There was previously no way to specify that a register operand cannot
have any writeback modifiers, and as a result the argument to vldr.16
and vstr.16 could be erroneously output with post-increment. This
change adds an operand specifier which forbids all writeback, and
selects it in the
"Kewen.Lin" writes:
> Hi Richard,
>
> Thanks for the review again!
>
> on 2020/7/25 上午12:21, Richard Sandiford wrote:
>> "Kewen.Lin" writes:
>>
>> Thanks, the rearrangement of the existing code looks good. Could you
>> split that and the new LOOP_VINFO_FULLY_WITH_LENGTH_P (loop_vinfo) stuff
>>
On Mon, Jul 27, 2020 at 02:32:15PM +0200, Martin Liška wrote:
> As mentioned in the PR, we should not create a string constant for a type
> that is different from char_type_node. Looking at expr.c, I was inspired
> and used 'TYPE_MAIN_VARIANT (chartype) == char_type_node' to verify that
>
"Kewen.Lin" writes:
> Hi,
>
> As Richard S. suggested in the thread:
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550633.html
>
> this patch is separated from the one of that thread, mainly to refactor the
> existing peel_iters_{pro,epi}logue cost model handlings.
>
> I've addressed
Sorry for the late reply!
-Original Message-
From: Richard Biener [mailto:rguent...@suse.de]
Sent: Wednesday, July 22, 2020 3:02 PM
> First of all I think giving users more control over vectorization is
> good. Now as for "#pragma GCC no_reduc_chain" I'd like to avoid
> negatives and
On Mon, Jul 27, 2020 at 2:54 PM Martin Liška wrote:
>
> On 7/27/20 2:51 PM, Richard Biener wrote:
> > On Mon, Jul 27, 2020 at 2:50 PM Andreas Schwab
> > wrote:
> >>
> >> On Jul 27 2020, Martin Liška wrote:
> >>
> >>> @Andreas: Is it a known issue?
> >>
> >> Which issue?
> >
> > I guess Martin
On 7/27/20 2:51 PM, Richard Biener wrote:
On Mon, Jul 27, 2020 at 2:50 PM Andreas Schwab wrote:
On Jul 27 2020, Martin Liška wrote:
@Andreas: Is it a known issue?
Which issue?
I guess Martin means the checking glibc done looks excessive
(for the specific case of realloc). But yes, it's
On Mon, Jul 27, 2020 at 2:50 PM Martin Liška wrote:
>
> On 7/27/20 1:22 PM, Richard Biener wrote:
> > I wonder what happens if we make vector lowering not allow the compare
> > expanded via expand_vec_cond_expr_p?
>
> So the following patch survives bootstrap and tests on x86_64-linux-gnu:
>
>
On Mon, Jul 27, 2020 at 2:50 PM Andreas Schwab wrote:
>
> On Jul 27 2020, Martin Liška wrote:
>
> > @Andreas: Is it a known issue?
>
> Which issue?
I guess Martin means the checking glibc done looks excessive
(for the specific case of realloc). But yes, it's enabled in the build roots
so we just
On 7/27/20 1:22 PM, Richard Biener wrote:
I wonder what happens if we make vector lowering not allow the compare
expanded via expand_vec_cond_expr_p?
So the following patch survives bootstrap and tests on x86_64-linux-gnu:
diff --git a/gcc/tree-vect-generic.c b/gcc/tree-vect-generic.c
index
On Jul 27 2020, Martin Liška wrote:
> @Andreas: Is it a known issue?
Which issue?
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Hi,
On Mon, Jul 27 2020, Richard Biener via Gcc-patches wrote:
> On Sat, Jul 25, 2020 at 8:35 PM Sergei Trofimovich via Gcc-patches
> wrote:
>>
>> From: Sergei Trofimovich
>>
>> In PR ipa/96291 the test contained an SCC with one
>> unoptimized function. This tricked ipa-cp into NULL
Hi,
On Sat, Jul 25 2020, Sergei Trofimovich wrote:
> From: Sergei Trofimovich
>
> In PR ipa/96291 the test contained an SCC with one
> unoptimized function. This tricked ipa-cp into NULL dereference.
>
> has_undead_caller_from_outside_scc_p() did not take into account
> that unoptimized funtions
Hey.
As mentioned in the PR, we should not create a string constant for a type
that is different from char_type_node. Looking at expr.c, I was inspired
and used 'TYPE_MAIN_VARIANT (chartype) == char_type_node' to verify that
underlying
type is a character type.
Patch can bootstrap on
Hi!
This patch makes the -falign-foo=0 work as described in the
documentation. Thanks for all the suggestions.
v4: do changes for coding conventions
v3: make change more readable and self-consistent
Changelog:
2020-07-27 Hu Jiangping
PR driver/96247
* opts.c
On Mon, Jul 27, 2020 at 1:24 PM Martin Liška wrote:
>
> On 7/27/20 1:11 PM, Jan Hubicka wrote:
> >> On 7/27/20 9:11 AM, Richard Biener wrote:
> >>> OK. I guess the previous code tried to use less memory.
> >>
> >> It did. But I didn't realize that such exact growth would lead
> >> to a massive
On 7/27/20 1:11 PM, Jan Hubicka wrote:
On 7/27/20 9:11 AM, Richard Biener wrote:
OK. I guess the previous code tried to use less memory.
It did. But I didn't realize that such exact growth would lead
to a massive reallocation for huge apps like chromium.
I would consider it an API issue -
On 7/27/20 1:03 PM, Jan Hubicka wrote:
Did you do chroot to the chromium build?
Oh, you are right!
It really takes move than 60 seconds with:
35.43% a.outlibc-2.31.so [.] mem2chunk_check
26.54% a.outlibc-2.31.so [.] mem2mem_check
21.50% a.outlibc-2.31.so
On Mon, Jul 27, 2020 at 11:32 AM Martin Liška wrote:
>
> On 7/10/20 10:24 AM, Richard Biener wrote:
> > On Fri, Jul 10, 2020 at 9:50 AM Martin Liška wrote:
> >>
> >> As mentioned in the PR, we need to clean up orphan vector comparisons
> >> that tend to happen be gimplification of VEC_COND_EXPR.
> On 7/27/20 9:11 AM, Richard Biener wrote:
> > OK. I guess the previous code tried to use less memory.
>
> It did. But I didn't realize that such exact growth would lead
> to a massive reallocation for huge apps like chromium.
I would consider it an API issue - it is not really at all that
On Mon, Jul 27, 2020 at 12:48 PM Jan Hubicka wrote:
>
> > Yes, I verified that.
> >
> > > I guess I can try
> > > to do some profiling since this problem did not show on Firefox (that i
> > > find odd given that Firefox is just about half of the size).
> >
> > Yep, I'm also surprised about it.
>
> It runs for me in:
>
> $ time ./a.out 10
>
> real 0m10.048s
> user 0m9.742s
> sys 0m0.305s
Did you do chroot to the chromium build?
>
> Note that there may be an interleaving load on the machine.
> Perf says:
>
> 55.40% a.outlibc-2.26.so [.] realloc
> 36.01%
On 7/27/20 12:25 PM, Richard Sandiford wrote:
So I don't think there's a different value that parse_and_check_align_values
could sensibly insert instead of zero.
All right, works for me.
Martin
On 7/27/20 12:48 PM, Jan Hubicka wrote:
Yes, I verified that.
I guess I can try
to do some profiling since this problem did not show on Firefox (that i
find odd given that Firefox is just about half of the size).
Yep, I'm also surprised about it.
Perhaps glibc has some stupid limit in
> Yes, I verified that.
>
> > I guess I can try
> > to do some profiling since this problem did not show on Firefox (that i
> > find odd given that Firefox is just about half of the size).
>
> Yep, I'm also surprised about it.
>
> > Perhaps glibc has some stupid limit in realloc that makes it
> > This patch makes the -falign-foo=0 work as described in the
> > documentation. Thanks for all the suggestions, Richard and Segher!
>
> Hello.
>
> I'm the author of the original code.
>
> >
> > v3: make change more readable and self-consistent
> > v2: at a high level handles -falign-foo=0
On Mon, Jul 27, 2020 at 11:45 AM Richard Sandiford
wrote:
>
> Richard Biener writes:
> > On Mon, Jul 27, 2020 at 11:09 AM Richard Sandiford
> > wrote:
> >>
> >> Richard Biener via Gcc-patches writes:
> >> > On Wed, Jul 22, 2020 at 5:18 PM Stefan Schulze Frielinghaus via
> >> > Gcc-patches
On 7/27/20 11:51 AM, Jan Hubicka wrote:
On 7/27/20 9:11 AM, Richard Biener wrote:
OK. I guess the previous code tried to use less memory.
It did. But I didn't realize that such exact growth would lead
to a massive reallocation for huge apps like chromium.
I'm going to backport the patch
Martin Liška writes:
> On 7/27/20 9:46 AM, Hu Jiangping wrote:
>> Hi!
>>
>> This patch makes the -falign-foo=0 work as described in the
>> documentation. Thanks for all the suggestions, Richard and Segher!
>
> Hello.
>
> I'm the author of the original code.
>
>>
>> v3: make change more readable
> On 7/27/20 9:11 AM, Richard Biener wrote:
> > OK. I guess the previous code tried to use less memory.
>
> It did. But I didn't realize that such exact growth would lead
> to a massive reallocation for huge apps like chromium.
>
> I'm going to backport the patch older releases as well.
Thank
On 27/07/20 11:41 +0200, Rainer Orth wrote:
Hi Jonathan,
This adds the missing std::from_chars overloads for floating-point
types, as required for C++17 conformance.
The implementation is a hack and not intended to be used in the long
term. Rather than parsing the string directly, this
Richard Biener writes:
> On Mon, Jul 27, 2020 at 11:09 AM Richard Sandiford
> wrote:
>>
>> Richard Biener via Gcc-patches writes:
>> > On Wed, Jul 22, 2020 at 5:18 PM Stefan Schulze Frielinghaus via
>> > Gcc-patches wrote:
>> >>
>> >> This is a follow up to commit 5c9669a0e6c respectively
Hi Jonathan,
> This adds the missing std::from_chars overloads for floating-point
> types, as required for C++17 conformance.
>
> The implementation is a hack and not intended to be used in the long
> term. Rather than parsing the string directly, this determines the
> initial portion of the
On 7/27/20 9:46 AM, Hu Jiangping wrote:
Hi!
This patch makes the -falign-foo=0 work as described in the
documentation. Thanks for all the suggestions, Richard and Segher!
Hello.
I'm the author of the original code.
v3: make change more readable and self-consistent
v2: at a high level
On 7/10/20 10:24 AM, Richard Biener wrote:
On Fri, Jul 10, 2020 at 9:50 AM Martin Liška wrote:
As mentioned in the PR, we need to clean up orphan vector comparisons
that tend to happen be gimplification of VEC_COND_EXPR.
I've done that easily in expand_vector_comparison where I add these
to
ping
On Mon, Jul 20, 2020 at 4:40 PM Hongtao Liu wrote:
>
> Correct PR number in ChangeLog
> it's pr96243.
>
> On Mon, Jul 20, 2020 at 1:46 PM Hongtao Liu wrote:
> >
> > Hi:
> > For rtx like (eq:HI (V8SI 90) (V8SI 91)), cse will take it as a
> > boolean value and try to do some optimization.
ping
On Wed, Jul 22, 2020 at 12:59 PM Hongtao Liu wrote:
>
> Those two define_insns have same pattern, and
> _load_mask would always be matched since it show up
> earlier in the md file, and it may lose some opportunity in
> pass_reload since _load_mask only have constraint "0C"
> for
ping
On Wed, Jul 22, 2020 at 3:57 PM Hongtao Liu wrote:
>
> Bootstrap is ok, regression test is ok for i386 backend.
>
> gcc/
> PR target/96262
> * config/i386/i386-expand.c
> (ix86_expand_vec_shift_qihi_constant): Refine.
>
> gcc/testsuite/
> *
1 - 100 of 131 matches
Mail list logo
