Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

Hi, Alexandre, CC’ing Richard for his comments on this. > On Aug 10, 2020, at 9:39 PM, Alexandre Oliva wrote: >> I think that moving how to zeroing the registers part to each target >> will be a better solution since each target has >> Better idea on how to use the most efficient insns to do

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

>> >>> If so, I am okay with name “call-clobbered” if this name sounds better. >> >> It's more obvious, at least to me. In the current option list of GCC: https://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code-Gen-Options

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

Hi, > On Aug 7, 2020, at 5:59 PM, Segher Boessenkool > wrote: > >> From my understanding (I am not a security expert though), this patch should >> serve two purpose: >> >> 1. Erase the registers upon return to avoid information leak; > > But only some of the registers. All the call-used

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

Hi, Alexandre, Thank you for the comments and suggestions. > On Aug 7, 2020, at 8:20 AM, Alexandre Oliva wrote: > > On Jul 28, 2020, Qing Zhao via Gcc-patches wrote: > >>> 2. The main code generation part is moved from i386 backend to middle-end; >>> 3. Add 4

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Aug 7, 2020, at 1:21 AM, Richard Biener wrote: > > On Thu, 6 Aug 2020, Kees Cook wrote: > >> On Thu, Aug 06, 2020 at 10:37:43AM +0200, Richard Biener wrote: >>> OK, so -fzero-call-used-regs is a ROP mitigation technique. To me >>> it sounded more like a mitigation against information

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

Hi, Segher, Thanks for your comments. > On Aug 6, 2020, at 6:37 PM, Segher Boessenkool > wrote: > > Hi! > > On Thu, Aug 06, 2020 at 10:31:27AM +0200, Richard Biener wrote: >> Jeff might be, but with the intended purpose (ROP mitigation AFAIU) >> it would be nice for other target maintainers

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

Hi, Richard, > On Aug 5, 2020, at 4:35 PM, Qing Zhao via Gcc-patches > wrote: > > >> >>>>>> + continue; >>>>>> + if (fixed_regs[regno]) >>>>>> + continue; >>>>>> + if (is_live_

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Aug 6, 2020, at 3:37 AM, Richard Biener wrote: > > On Wed, 5 Aug 2020, Qing Zhao wrote: > >>>> >>>> From The SECURE project and GCC in GCC Cauldron 2018: >>>> >>>> Speaker: Graham Markall >>>> >>>&g

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Aug 6, 2020, at 3:31 AM, Richard Biener wrote: > > On Wed, 5 Aug 2020, Qing Zhao wrote: > >> Hi, Richard, >> >> Thanks a lot for your careful review and detailed comments. >> >> >>> On Aug 4, 2020, at 2:35 AM, Richard Biener &g

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

Hi, Richard, Thanks a lot for your careful review and detailed comments. > On Aug 4, 2020, at 2:35 AM, Richard Biener wrote: > > I have a few comments below - I'm not sure I'm qualified to fully > review the rest though. Could you let me know who will be the more qualified person to fully

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

>> >> From The SECURE project and GCC in GCC Cauldron 2018: >> >> Speaker: Graham Markall >> >> The SECURE project is a 15 month program funded by Innovate UK, to >> take well known security techniques from academia and make them >> generally available in standard compilers, specfically GCC and

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Aug 5, 2020, at 9:45 AM, H.J. Lu wrote: > > On Wed, Aug 5, 2020 at 5:34 AM H.J. Lu > wrote: >> >> On Wed, Aug 5, 2020 at 5:31 AM Richard Biener wrote: >>> >>> >>> [PATCH] Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

Re: PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

jul. 2020 je oseba Qing Zhao <mailto:qing.z...@oracle.com>> napisala: > > > > > > Richard and Uros, > > > > Could you please review the change that H.J and I rewrote based on your > > comments in the previous round of discussion? > > > > This

PING [Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

> On Jul 14, 2020, at 9:45 AM, Qing Zhao via Gcc-patches > wrote: > > Hi, Gcc team, > > This patch is a follow-up on the previous patch and corresponding discussion: > https://gcc.gnu.org/pipermail/gcc-patches/2020-May/545101.html > <https://gcc.gnu.org/pipermail/gcc-p

Re: [stage1][PATCH] Change semantics of -frecord-gcc-switches and add -frecord-gcc-switches-format.

Hi, Thanks a lot for the info. > On Jul 23, 2020, at 5:07 AM, Martin Liška wrote: > > On 7/21/20 6:24 PM, Qing Zhao wrote: >> 4. >> Our company is waiting for this patch to be committed to upstream. > > Hello. > > Please note that patch review can sometimes t

Re: [stage1][PATCH] Change semantics of -frecord-gcc-switches and add -frecord-gcc-switches-format.

PING^4. Our company is waiting for this patch to be committed to upstream. Thanks a lot. Qing > On Jun 16, 2020, at 7:49 AM, Martin Liška wrote: > > PING^3 > > On 6/2/20 11:16 AM, Martin Liška wrote: >> PING^2 >> On 5/15/20 11:58 AM, Martin Liška wrote: >>> We're in stage1: PING^1 >>> >>>

[Patch][Middle-end]Add -fzero-call-used-regs=[skip|used-gpr|all-gpr|used|all]

any more comment? thanks. Qing gcc/ChangeLog: 2020-07-13 qing zhao mailto:qing.z...@oracle.com>> 2020-07-13 H.J. Lu mailto:hjl.to...@gmail.com>> * common.opt: Add new option -fzero-call-used-regs. * config/i386/i386.c (ix86_z

Re: PING[STAGE 1][PATCH][x86][1/3]: Add -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all]

Hi, Kees, > On May 4, 2020, at 1:21 PM, Kees Cook wrote: > > On Mon, May 04, 2020 at 11:51:49AM -0500, Qing Zhao wrote: >> Hi, >> >> This is a PING for this patch for gcc11 stage 1. >> >> https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544058.html

Committed [Version 3][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

FYI. > On Apr 23, 2020, at 5:13 PM, David Malcolm wrote: > > May need updating to match the hint message. > > [...] > > This is OK for stage 1 with those nits fixed. I committed the updated patch with all the suggestions today to gcc11 stage1 as:

PING[STAGE 1][PATCH][x86][1/3]: Add -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all]

Hi, This is a PING for this patch for gcc11 stage 1. https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544058.html <https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544058.html> Please take a look on it. Thanks. Qing > Begin forwarded message: > > From: Qing Zhao

Re: [Version 4][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

Hi, David, > On Apr 24, 2020, at 5:36 PM, David Malcolm wrote: > > On Fri, 2020-04-24 at 17:22 -0500, Qing Zhao wrote: >> Hi, Dave, >> >> Thanks a lot for the review and comments. >> I just updated the patch with all your suggestions, bootstrapped it >>

[Version 4][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

. Qing gcc/c-family/ChangeLog: 2020-04-24 qing zhao * c-indentation.c (get_visual_column): Add a hint to use the new -flarge-source-files option. gcc/ChangeLog: 2020-04-24 qing zhao * common.opt: Add -flarge-source-files. * doc/invoke.texi: Document

[Version 3][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

Hi, Richard, This is the 3rd version of the patch, updated based on your previous comments. Please take a look at it and let me know whether it’s okay to commit? Thanks a lot for all your help. Qing. gcc/ChangeLog: 2020-04-22 qing zhao PR c/94230 * common.opt: Add -flarge

Re: [Version 2][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

Hi, Richard, > On Apr 23, 2020, at 1:27 PM, Richard Sandiford > wrote: > > Qing Zhao writes: >> --- >> gcc/c-family/c-indentation.c | 3 +++ >> gcc/common.opt |

[Version 2][PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

. Documentation for this new option; 4. Update the testing case location-overflow-test-1.c to include the new hint. Please take a look at this new patch and let me know any new comment. thanks. Qing. gcc/ChangeLog: 2020-04-22 qing zhao PR c/94230 * common.opt: Add -flarge-source-files

Re: PING [PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

Hi, Richard And Dave: Thanks a lot for the review and comments. > On Apr 21, 2020, at 1:46 PM, Richard Sandiford > wrote: > > David Malcolm writes: >> On Tue, 2020-04-21 at 15:04 +0100, Richard Sandiford wrote >>> >>> Please add: >>> >>> PR c/94230 Will do. >>> *

[PATCH][x86][1/3]: Add -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all]

Hi, This is a PING for an old patch proposed by H. J. Lu on Oct, 2018: https://gcc.gnu.org/legacy-ml/gcc-patches/2018-10/msg02079.html This is the first patch of the total 3 patches set, which provides the following new feature: -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all]

[PATCH][x86][2/3]: Add -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all]

Hi, This is the 2nd patch of the total 3 patches set for providing the new feature -mzero-caller-saved-regs for linux kernel security improvement. This patch is for resolving the new regressions triggered by the first patch. This patch is to Add ix86_any_return_p to check simple_return in a

[PATCH][x86][3/3]: Add -mzero-caller-saved-regs=[skip|used-gpr|all-gpr|used|all]

Hi, This is the 3rd patch of the total 3 patches set for providing the new feature -mzero-caller-saved-regs for linux kernel security improvement. This patch is to Update gcc.target/i386/ret-thunk-2[234].c Qing 0003-Update-gcc.target-i386-ret-thunk-2-234-.c.patch Description: Binary data

Fwd: PING [PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

Ping. We need this patch for our product building. thanks. Qing > Begin forwarded message: > > From: Qing Zhao via Gcc-patches > Subject: PING [PATCH][gcc][PR94230]provide an option to change the size > limitation for -Wmisleading-indent > Date: April 8, 2020 at 2:39:22

PING [PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

Hi, Please take a look at the attached patch and let me know your comments. Thanks. Qing gcc/ChangeLog: 2020-04-03 qing zhao * common.opt: Add -flocation-ranges. * doc/invoke.texi: Document it. * toplev.c (process_options): set line_table->default_range_b

[PATCH][gcc][PR94230]provide an option to change the size limitation for -Wmisleading-indent

Hi, David and Jakub, Per the discussion we had for PR94230: provide an option to change the size limitation for -Wmisleading-indent https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230 I come up with the following simple patch per David’s

Re: PING*2 : Fwd: [PATCH][gcov-profile/91971]Profile directory concatenated with object file path

Thank you! Just committed the change at: https://gcc.gnu.org/viewcvs/gcc?view=revision=277344 <https://gcc.gnu.org/viewcvs/gcc?view=revision=277344> Qing > On Oct 23, 2019, at 5:15 AM, Martin Liška wrote: > > On 10/21/19 5:32 PM, Qing Zhao wrote: >> Please let me kn

PING*2 : Fwd: [PATCH][gcov-profile/91971]Profile directory concatenated with object file path

Hi, This is 2nd ping of this simple patch. We are waiting for this patch for one of our important project. Please let me know whether this patch is reasonable or not. Thanks a lot. Qing > Begin forwarded message: > > From: Qing Zhao > Subject: PING: Fwd: [PATCH][gcov-profile/9

PING: Fwd: [PATCH][gcov-profile/91971]Profile directory concatenated with object file path

Hi, This is a ping to the following patch. Thanks, Qing > Begin forwarded message: > > From: Qing Zhao > Subject: [PATCH][gcov-profile/91971]Profile directory concatenated with > object file path > Date: October 9, 2019 at 10:30:04 AM CDT > To: hubi...@ucw.cz > Cc:

[PATCH][gcov-profile/91971]Profile directory concatenated with object file path

Hi, This is a patch for fix PR 91971: Profile directory concatenated with object file path https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91971 Gcc/ChangeLog: +2019-10-09 qing zhao + + * coverage.c (coverage_init): Mangle the full path of filename when + filename is a absolute

Ping: question on Multiple level macro expansion

Hi, This is a ping on: https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01628.html Anyway, I filed a gcc bug on this issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91973 If you

Ping ---A bug with -fprofile-dir? Profile directory concatenated with object file path

Ping on: https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01554.html Anyway, I filed an gcc bug on this issue as: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91971 If you think that

question on Multiple level macro expansion

Hi, GCC cannot compile the following small testing case: [qinzhao@localhost]$ cat t1.c extern void boo (void *addr); #define foo(addr) \ boo (addr) #define bar(instr, addr) \ (instr) (addr) void check (void *addr) { bar(foo, addr); } [qinzhao@localhost]$ sh t

A bug with -fprofile-dir? Profile directory concatenated with object file path

Hi, we noticed that the profile directory will be concatenated with object file path. the following small example explain this behavior: [qinzhao@localhost small]$ cat t #! /bin/bash CC=/home/qinzhao/Install/latest/bin/gcc opt="-O3 -fprofile-generate" opt="$opt

[PATCH][Preprocessor][Version 3]patch to fix PR 90581

Hi, this is the 3rd version of the patch, which fixed the issues Paolo raised in the previous email. Okay for trunk? thanks. gcc/ChangeLog: 2019-06-03 qing zhao * doc/cppopts.texi: Add document for -fmax-include-depth. * doc/invoke.texi (Preprocessor Options): List -fmax

Re: [PATCH][Preprocessor][Version 3]patch to fix PR 90581

Hi, Paolo, thanks for the comment. I will fix these issues. Qing > On Jun 3, 2019, at 10:03 AM, Paolo Carlini wrote: > > Hi, > > a few minor comments. > > On 03/06/19 16:49, Qing Zhao wrote: >> +fmax-include-depth= >> +C ObjC C++ ObjC++ Joined RejectN

[PATCH][Preprocessor][Version 2]patch to fix PR 90581

Hi, this is the 2nd version of the patch. the main changes are: 1. some typo. 2. enhance the error message to provide user idea on how to increase the limit. bootstrap and regression tested on X86, no issue. Okay for trunk? thanks. Qing gcc/ChangeLog: 2019-06-03 qing zhao

Re: [PATCH][Preprocessor]patch to fix PR 90581

> On May 30, 2019, at 3:46 PM, David Malcolm wrote: > > On Thu, 2019-05-30 at 11:23 -0500, Qing Zhao wrote: >> Hi, >> >> PR 90581 (provide an option to adjust the maximum depth of nested >> #include) >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581

Re: [PATCH][Preprocessor]patch to fix PR 90581

> On May 30, 2019, at 3:38 PM, David Malcolm wrote: > > On Thu, 2019-05-30 at 15:17 -0500, Qing Zhao wrote: >>> On May 30, 2019, at 2:13 PM, Bernhard Reutner-Fischer >> gmail.com> wrote: >>> >>> On 30 May 2019 18:23:43 CEST, Qing Zhao >

Re: [PATCH][Preprocessor]patch to fix PR 90581

> On May 30, 2019, at 2:13 PM, Bernhard Reutner-Fischer > wrote: > > On 30 May 2019 18:23:43 CEST, Qing Zhao wrote: >> Hi, >> >> PR 90581 (provide an option to adjust the maximum depth of nested >> #include) >> https://gcc.gnu.org/bugzilla/show_b

[PATCH][Preprocessor]patch to fix PR 90581

include. The default value is 200. Please check the attached patch. I have done bootstrap and regression test on X86, no any issue. thanks a lot. Qing. gcc/ChangeLog: 2019-05-30 qing zhao * doc/cppopts.texi: Add document for -fmax-include-depth. * doc/invoke.texi

Re: Question on adding an option control to libcpp

Okay. thanks, I will add testing cases. Qing > On May 28, 2019, at 4:26 PM, David Malcolm wrote: > > On Tue, 2019-05-28 at 15:08 -0500, Qing Zhao wrote: >> Hi, David, >> >> for this new option, do I need to add a new testing case for it? > > Yes please. I

Re: Question on adding an option control to libcpp

Hi, David, for this new option, do I need to add a new testing case for it? if so, where should I put this new testing case? thanks. Qing > On May 24, 2019, at 1:47 PM, David Malcolm wrote: > > On Fri, 2019-05-24 at 11:59 -0500, Qing Zhao wrote: >> Hi, >> >&

Re: Question on adding an option control to libcpp

Hi, David, this is helpful. thanks. Qing > On May 24, 2019, at 1:47 PM, David Malcolm wrote: > > On Fri, 2019-05-24 at 11:59 -0500, Qing Zhao wrote: >> Hi, >> >> in order to fix PR90581: (provide an option to adjust the maximum >> depth of nested #in

Question on adding an option control to libcpp

Hi, in order to fix PR90581: (provide an option to adjust the maximum depth of nested #include) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90581 we need to add a new option to preprocessor. where should I put this option? I tried to

Re: [PATCH][Version 3]Come up with -flive-patching master option.

Hi, Jonathan, thanks for your review on the documentation change for -flive-patching option. > >> --- a/gcc/doc/invoke.texi >> +++ b/gcc/doc/invoke.texi >> @@ -416,6 +416,7 @@ Objective-C and Objective-C++ Dialects}. >> -fipa-bit-cp -fipa-vrp @gol >> -fipa-pta -fipa-profile -fipa-pure-const

Re: [PATCH][Tree-optimization/PR89730]grant always_inline when -flive-patching=inline-only-static

> On Mar 28, 2019, at 11:30 AM, Qing Zhao wrote: > > Thanks. > > I updated ipa-inline.c as you suggested, and tested the gcc with all > live-patching-*.c testing cases, all were fine. > bootstrapped on aarch64, and now the regression testing is running. the regressio

Re: [PATCH][Tree-optimization/PR89730]grant always_inline when -flive-patching=inline-only-static

Thanks. I updated ipa-inline.c as you suggested, and tested the gcc with all live-patching-*.c testing cases, all were fine. bootstrapped on aarch64, and now the regression testing is running. the new patch is as following: Okay for trunk? thanks. Qing gcc/ChangeLog: 2019-03-28 qing zhao

Re: [PATCH][Tree-optimization/PR89730]grant always_inline when -flive-patching=inline-only-static

t 7:23 AM, Richard Biener > wrote: > > On Wed, Mar 20, 2019 at 4:16 PM Qing Zhao wrote: >> >> Hi, >> >> there is a bug in the current support for -flive-patching=inline-only-static: >> >> it rejects inlining of external always_inline routine,

[PATCH][Tree-optimization/PR89730]grant always_inline when -flive-patching=inline-only-static

bootstrapped and regression tested on aarch64. Okay for committing? thanks. Qing. gcc/ChangeLog: 2019-03-20 qing zhao PR tree-optimization/89730 * ipa-inline.c (can_inline_edge_p): Grant always_inline even when -flive-patching=inline-only-static. gcc/testsuite

Re: A bug in vrp_meet?

> On Mar 5, 2019, at 8:44 AM, Richard Biener wrote: > will you commit this fix to gcc9 and gcc8 (we need it in gcc8)? >>> >>> I'll see to carve out some cycles trying to find a testcase and amend >>> the fix a bit >>> and will take care of testing/submitting the fix. Thanks

Re: A bug in vrp_meet?

> On Mar 5, 2019, at 4:44 AM, Richard Biener wrote: > >>> >>> will you commit this fix to gcc9 and gcc8 (we need it in gcc8)? >> >> I'll see to carve out some cycles trying to find a testcase and amend >> the fix a bit >> and will take care of testing/submitting the fix. Thanks for testing

Re: A bug in vrp_meet?

Hi, Richard, > On Mar 4, 2019, at 5:45 AM, Richard Biener wrote: >> >> It looks like DOM fails to visit stmts generated by simplification. Can you >> open a bug report with a testcase? >> >> >> The problem is, It took me quite some time in order to come up with a small >> and independent

Re: A bug in vrp_meet?

Richard, thanks a lot for your suggested fix. I will try it. Qing > On Mar 4, 2019, at 5:45 AM, Richard Biener wrote: > > On Fri, Mar 1, 2019 at 10:02 PM Qing Zhao wrote: >> >> >> On Mar 1, 2019, at 1:25 PM, Richard Biener >> wrote: >> >>

Re: A bug in vrp_meet?

> On Mar 1, 2019, at 1:25 PM, Richard Biener wrote: > > On March 1, 2019 6:49:20 PM GMT+01:00, Qing Zhao <mailto:qing.z...@oracle.com>> wrote: >> Jeff, >> >> thanks a lot for the reply. >> >> this is really helpful. >> >>

Re: A bug in vrp_meet?

, at 1:54 PM, Jeff Law wrote: > > On 2/28/19 10:05 AM, Qing Zhao wrote: >> Hi, >> >> I have been debugging a runtime error caused by value range propagation. and >> finally located to the following gcc routine: >> >> vrp_meet_1 in gcc/tree-vrp.c >>

A bug in vrp_meet?

Hi, I have been debugging a runtime error caused by value range propagation. and finally located to the following gcc routine: vrp_meet_1 in gcc/tree-vrp.c /* Meet operation for value ranges. Given two value ranges VR0 and VR1, store in VR0 a range that contains both VR0 and VR1.

Re: Set inline-unit-growth to 40

Okay, I see. thanks. Qing > On Jan 15, 2019, at 9:14 AM, Jan Hubicka wrote: > >> Hi, Honza, >> >> in addition to the code size problems, there are several runtime regression >> for the SPEC: (If I read the table correctly, if not, let me know) >> >> SPEC/SPEC2006/INT/483.xalancbmk >>

Re: Set inline-unit-growth to 40

Hi, Honza, in addition to the code size problems, there are several runtime regression for the SPEC: (If I read the table correctly, if not, let me know) SPEC/SPEC2006/INT/483.xalancbmk 146.131 4.89%

Re: Remove overall growth from badness metrics

>>> >>> Those are sizes of libxul, which is the largest library of Firefox. >>> PGO is profile guided optimization. >> >> Okay. I see. >> >> looks like for LTO, the code size increase with profiling is much smaller >> than >> that without profiling when growth is increased from 20% to 40%.

Re: Remove overall growth from badness metrics

> On Jan 8, 2019, at 11:53 AM, Jan Hubicka wrote: > >>> >>> In general this parameter affects primarily -O3 builds, becuase -O2 >>> hardly hits the limit. From -O3 only programs with very large units are >>> affected (-O2 units hits the limit only if you do have a lot of inline >>> hints in

Re: Remove overall growth from badness metrics

> On Jan 8, 2019, at 5:46 AM, Jan Hubicka wrote: > >>> I plan to commit the patch tomorrow after re-testing everything after >>> the bugfixes from today and yesterday. In addition to this have found >>> that current inline-unit-growth is too small for LTO of large programs >>> (especially

Re: Remove overall growth from badness metrics

> On Jan 6, 2019, at 5:52 PM, Jan Hubicka wrote: > > Hi, > this patch removes overall growth from badness metrics. This code was > added at a time inliner was purely function size based to give a hint > that inlining more different functions into all callers is better than > inlining one

Re: [PATCH][Version 3]Come up with -flive-patching master option.

thanks a lot for fixing this issue. Qing > On Dec 7, 2018, at 7:07 AM, Rainer Orth wrote: > > Hi Qing, > >>> On Nov 28, 2018, at 9:52 AM, Jan Hubicka wrote: >>> >>>> >>>> 2018-11-20 qing zhao >>>> >>>>* c

Question on Disable no throw for -flive-patching master option.

this pass? what’s your opinion on this? thanks. Qing > On Nov 28, 2018, at 2:24 PM, Qing Zhao wrote: >> >> Shall we also disable nothrow or we will worry about C++ only ter? > > This is also mainly for C++ applications, so currently should not be a > problem. &g

Re: [PATCH][Version 3]Come up with -flive-patching master option.

the patch has been committed today as: https://gcc.gnu.org/viewcvs/gcc?view=revision=266627 <https://gcc.gnu.org/viewcvs/gcc?view=revision=266627> I will try to update the gcc9 change page soon. thanks. Qing > On Nov 28, 2018, at 2:24 PM, Qing Zhao wrote: > >> >>

Re: [PATCH][Version 3]Come up with -flive-patching master option.

> On Nov 28, 2018, at 9:52 AM, Jan Hubicka wrote: > >> >> 2018-11-20 qing zhao >> >> * cif-code.def (EXTERN_LIVE_ONLY_STATIC): New CIF code. >> * common.opt: Add -flive-patching flag. >> * doc/invoke.texi: Document -fl

Re: [PATCH]Come up with -flive-patching master option.

> On Nov 16, 2018, at 9:51 AM, Jan Hubicka wrote: > >> On 11/16/18 2:36 AM, Qing Zhao wrote: >>> Hi, >>> >>> this is the new version of the patch. >>> >>> I have bootstrapped it on both aarch64 and x86, no regression. >>&

Re: [PATCH][RFC] Come up with -flive-patching master option.

Hi, > On Nov 13, 2018, at 1:18 PM, Miroslav Benes wrote: > >> Attached is the patch for new -flive-patching=[inline-only-static | >> inline-clone] master option. >> >> '-flive-patching=LEVEL' >> Control GCC's optimizations to provide a safe compilation for >> live-patching. Provides

[PATCH][RFC] Come up with -flive-patching master option.

g flive-patching.patch Description: Binary data > On Nov 12, 2018, at 4:29 PM, Qing Zhao wrote: > > >> On Nov 12, 2018, at 2:53 AM, Martin Liška wrote: >> >>> >>> Okay, I see. >>> >>> I am also working on a similar opti

Re: [PATCH][RFC] Come up with -flive-patching master option.

> On Nov 12, 2018, at 2:53 AM, Martin Liška wrote: > >> >> Okay, I see. >> >> I am also working on a similar option as yours, but make the -flive-patching >> as two level control: >> >> +flive-patching >> +Common RejectNegative Alias(flive-patching=,inline-clone) >> + >> +flive-patching=

Re: [PATCH][RFC] Come up with -flive-patching master option.

Hi, > On Nov 10, 2018, at 2:51 AM, Martin Liška wrote: > > On 11/9/18 6:43 PM, Qing Zhao wrote: >> Hi, Martin, >> >> thanks a lot for the previous two new options for live-patching. >> >> >> I have two more questions below: > > Hello. &

Re: [PATCH][RFC] Come up with -flive-patching master option.

Hi, Martin, thanks a lot for the previous two new options for live-patching. I have two more questions below: 1. do we still need new options to disable the following: A. unreachable code/variable removal? B. Visibility changes with -flto and/or -fwhole-program? 2. for this new patch,

Re: GCC options for kernel live-patching (Was: Add a new option to control inlining only on static functions)

>>> - ipa-pta (disabled by default, -fno-ipa-pta) - ipa-reference (list of accessed/modified global vars), disable by -fno-ipa-refernece - stack alignment requirements (no flag to disable) >>> >>> Would it be possible to add flag for it? Can you please point to a location

Re: [RFC] GCC support for live-patching

> On Oct 23, 2018, at 4:11 AM, Miroslav Benes wrote: >> >> One question here, what’s the major benefit to prepare the patches >> manually? > > I could almost quote what you wrote below. It is a C file, easy to review > and maintain. You have everything "under control". It allows to

Re: [RFC] GCC support for live-patching

Hi, thanks for the comments. > > thanks for the proposal. The others have already expressed some of my > worries and remarks, but I think it would be only right to write them > again. Especially since I am part of the team responsible for > implementation and maintenance of live patches

Re: GCC options for kernel live-patching (Was: Add a new option to control inlining only on static functions)

> On Oct 3, 2018, at 4:04 AM, Jan Hubicka wrote: > >> >> That was promised to be done by Honza Hubička. He's very skilled in IPA >> optimizations and he's aware >> of optimizations that cause troubles for live-patching. > > :) I am not sure how skilful I am, but here is what I arrived to. >

Re: GCC options for kernel live-patching (Was: Add a new option to control inlining only on static functions)

> On Oct 2, 2018, at 9:55 AM, Martin Liška wrote: Affected functions: 5 __ilog2_u64/132 (include/linux/log2.h:40:5) ablkcipher_request_alloc/1639 (include/linux/crypto.h:979:82) ablkcipher_request_alloc.constprop.8/3198 (include/linux/crypto.h:979:82)

Re: GCC options for kernel live-patching (Was: Add a new option to control inlining only on static functions)

> On Oct 2, 2018, at 9:02 AM, Martin Liška wrote: > > On 10/2/18 3:28 PM, Qing Zhao wrote: >> >>> On Oct 2, 2018, at 3:33 AM, Martin Jambor wrote: >>> >>> Hi, >>> >>> my apologies for being terse, I'm in a meeting. &g

Re: GCC options for kernel live-patching (Was: Add a new option to control inlining only on static functions)

> On Oct 2, 2018, at 3:33 AM, Martin Jambor wrote: > > Hi, > > my apologies for being terse, I'm in a meeting. > > On Mon, Oct 01 2018, Qing Zhao wrote: >> Hi, Martin, >> >> I have studied a little more on >> >> https://github.co

Re: GCC options for kernel live-patching (Was: Add a new option to control inlining only on static functions)

Hi, Martin, I have studied a little more on https://github.com/marxin/kgraft-analysis-tool/blob/master/README.md in the Section “Usages”, from the example, we can see: the tool will report a list of affected functions for

Re: GCC options for kernel live-patching (Was: Add a new option to control inlining only on static functions)

Thanks, Martin, for all these interesting information. Looks like that a more general option to help live-patching is needed. I will do a little more study on this direction. Qing > On Sep 27, 2018, at 7:19 AM, Martin Jambor wrote: > > Hi, > > (this message is a part of the thread

Re: [PATCH][Middle-end][Version 4]Add a new option to control inlining only on static functions

> On Sep 27, 2018, at 3:58 AM, Jan Hubicka wrote: > >> >> Okay, I see. >> >>> >>> If you make this to be INTERPOSABLE (which means it can be replaced by >>> different >>> implementation by linker and that is probably what we want for live >>> patching) >>> then also inliner, ipa-sra and

Re: [PATCH][Middle-end][Version 4]Add a new option to control inlining only on static functions

> On Sep 27, 2018, at 2:45 AM, Richard Biener wrote: > > On Wed, 26 Sep 2018, Qing Zhao wrote: > >> >>> On Sep 26, 2018, at 6:07 PM, Alexander Monakov wrote: >>> >>> On Wed, 26 Sep 2018, Qing Zhao wrote: >>>> The request i

Re: [PATCH][Middle-end][Version 4]Add a new option to control inlining only on static functions

> On Sep 26, 2018, at 6:07 PM, Alexander Monakov wrote: > > On Wed, 26 Sep 2018, Qing Zhao wrote: >> The request is for application developers who want to use gcc's online >> patching feature. >> >> Today, developers can turn off inlining and del

Re: [PATCH][Middle-end][Version 4]Add a new option to control inlining only on static functions

> On Sep 26, 2018, at 10:16 AM, Alexander Monakov wrote: > > On Wed, 26 Sep 2018, Qing Zhao wrote: > >> Alexander, >> >> thanks for the questions. >> >> Yes, we had some discussion on the questions you raised during the review of >> the

Re: [PATCH][Middle-end][Version 4]Add a new option to control inlining only on static functions

> On Sep 26, 2018, at 12:16 PM, Jan Hubicka wrote: > >>> >>> On Sep 26, 2018, at 10:06 AM, Jan Hubicka wrote: >>> On Wed, Sep 26, 2018 at 10:45 AM, Jeff Law wrote: > On 9/26/18 7:38 AM, Jason Merrill wrote: >> On Wed, Sep 26, 2018 at 9:24 AM, Richard Biener >> wrote:

Re: [PATCH][Middle-end][Version 4]Add a new option to control inlining only on static functions

> On Sep 26, 2018, at 12:16 PM, Jan Hubicka > wrote: > >>> >>> On Sep 26, 2018, at 10:06 AM, Jan Hubicka >> > wrote: >>> On Wed, Sep 26, 2018 at 10:45 AM, Jeff Law >>> > wrote: > On 9/26/18 7:38 AM, Jason Merrill

Re: [PATCH][Middle-end][Version 4]Add a new option to control inlining only on static functions

> On Sep 26, 2018, at 11:02 AM, Jan Hubicka wrote: > >>> Not sure >>> what 'internal' would mean in this context. >>> >>> But then the implementation looks at callee->externally_visible which >>> matches hidden visibility... externally_visible is probably not >>> the very best thing to look

Re: [PATCH][Middle-end][Version 4]Add a new option to control inlining only on static functions

> On Sep 26, 2018, at 10:06 AM, Jan Hubicka wrote: > >> On Wed, Sep 26, 2018 at 10:45 AM, Jeff Law wrote: >>> On 9/26/18 7:38 AM, Jason Merrill wrote: On Wed, Sep 26, 2018 at 9:24 AM, Richard Biener wrote: > IIRC he explicitely wanted 'static' not 'hidden' linkage. Not sure >

Re: [PATCH][Middle-end][Version 4]Add a new option to control inlining only on static functions

> On Sep 26, 2018, at 9:45 AM, Jeff Law wrote: > > On 9/26/18 7:38 AM, Jason Merrill wrote: >> On Wed, Sep 26, 2018 at 9:24 AM, Richard Biener wrote: >>> IIRC he explicitely wanted 'static' not 'hidden' linkage. Not sure >>> what 'internal' would mean in this context. >> >> I mean internal

Re: [PATCH][Middle-end][Version 4]Add a new option to control inlining only on static functions

> On Sep 26, 2018, at 8:24 AM, Richard Biener wrote: > > On Wed, 26 Sep 2018, Jason Merrill wrote: > >> On Fri, Sep 21, 2018 at 11:12 AM, Qing Zhao wrote: >>> Hi, this is the 4th version of the patch. >>> >>> mainly address Martin’s comments on

Re: [PATCH][Middle-end][Version 4]Add a new option to control inlining only on static functions

; On Fri, 21 Sep 2018, Qing Zhao wrote: >> +2018-09-20 Qing Zhao >> + >> +* cif-code.def (FUNCTION_EXTERN): New CIFCODE. >> +* common.opt (-finline-only-static): New option. >> +* doc/invoke.texi: Document -finline-only-static. >> +*

PING: [PATCH][Middle-end][Version 4]Add a new option to control inlining only on static functions

Hi, I’d like to ping the following patch. https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01238.html Thanks. Qing

<    6   7   8   9   10   11   12   >