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

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

[Qing Zhao]

[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]

Hi,

this is the 3rd version of the patch, the major change is to address Andrew’s concern on the documentation part.

I updated the documentation of this option as following:

'-finline-only-static'
     By default, GCC inlines functions without considering whether they
     are static or not.  This flag guides inliner to only inline static
     functions.  This option has any effect only when inlining itself is
     turned on by the -finline-functions or -finline-small-fiunctions.

     Off by default.

all other changes keep the same as version 2.

please take a look again. and let me know any comment and suggestion.

thanks.

Qing

gcc/ChangeLog

+2018-09-18  Qing Zhao  <qing.zhao@oracle.com>
+
+	* cif-code.def (FUNCTION_EXTERN): New CIFCODE.
+	* common.opt (-finline-only-static): New option.
+	* doc/invoke.texi: Document -finline-only-static.
+	* ipa-inline.c (can_inline_edge_p): Control inlining based on
+	function's visibility. 

gcc/testsuite/ChangeLog

+2018-09-18  Qing Zhao  <qing.zhao@oracle.com>
+
+	* gcc.dg/inline_only_static.c: New test.
+


[-- Attachment #2: New-inline-only-static.patch --]
[-- Type: application/octet-stream, Size: 4004 bytes --]

---
 gcc/cif-code.def                          |  6 ++++++
 gcc/common.opt                            |  4 ++++
 gcc/doc/invoke.texi                       | 12 +++++++++++-
 gcc/ipa-inline.c                          |  6 ++++++
 gcc/testsuite/gcc.dg/inline_only_static.c | 22 ++++++++++++++++++++++
 5 files changed, 49 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/inline_only_static.c

diff --git a/gcc/cif-code.def b/gcc/cif-code.def
index 19a7621..64b2b1a 100644
--- a/gcc/cif-code.def
+++ b/gcc/cif-code.def
@@ -132,6 +132,12 @@ DEFCIFCODE(USES_COMDAT_LOCAL, CIF_FINAL_ERROR,
 DEFCIFCODE(ATTRIBUTE_MISMATCH, CIF_FINAL_ERROR,
 	   N_("function attribute mismatch"))
 
+/* We can't inline because the user requests only inlining static function 
+   but the function is external visible.  */
+DEFCIFCODE(FUNCTION_EXTERN, CIF_FINAL_ERROR,
+	   N_("function is external visible when the user requests only"
+	      " inlining static"))
+
 /* We proved that the call is unreachable.  */
 DEFCIFCODE(UNREACHABLE, CIF_FINAL_ERROR,
 	   N_("unreachable"))
diff --git a/gcc/common.opt b/gcc/common.opt
index ef6a630..9c66a56 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1633,6 +1633,10 @@ finline-atomics
 Common Report Var(flag_inline_atomics) Init(1) Optimization
 Inline __atomic operations when a lock free instruction sequence is available.
 
+finline-only-static
+Common RejectNegative Var(flag_inline_only_static) Init(0) 
+Inline functions only when they are declared \"static\". 
+
 fcf-protection
 Common RejectNegative Alias(fcf-protection=,full)
 
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index ec12711..b6b0db5 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -407,7 +407,8 @@ Objective-C and Objective-C++ Dialects}.
 -fgcse-sm  -fhoist-adjacent-loads  -fif-conversion @gol
 -fif-conversion2  -findirect-inlining @gol
 -finline-functions  -finline-functions-called-once  -finline-limit=@var{n} @gol
--finline-small-functions  -fipa-cp  -fipa-cp-clone @gol
+-finline-only-static @gol
+-finline-small-functions -fipa-cp  -fipa-cp-clone @gol
 -fipa-bit-cp -fipa-vrp @gol
 -fipa-pta  -fipa-profile  -fipa-pure-const  -fipa-reference  -fipa-icf @gol
 -fira-algorithm=@var{algorithm} @gol
@@ -8066,6 +8067,15 @@ having large chains of nested wrapper functions.
 
 Enabled by default.
 
+@item -finline-only-static
+@opindex finline-only-static
+By default, GCC inlines functions without considering whether they are static 
+or not. This flag guides inliner to only inline static functions. 
+This option has any effect only when inlining itself is turned on by the 
+-finline-functions or -finline-small-fiunctions. 
+
+Off by default.
+
 @item -fipa-sra
 @opindex fipa-sra
 Perform interprocedural scalar replacement of aggregates, removal of
diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
index 0257885..f432243 100644
--- a/gcc/ipa-inline.c
+++ b/gcc/ipa-inline.c
@@ -376,6 +376,12 @@ can_inline_edge_p (struct cgraph_edge *e, bool report,
       e->inline_failed = CIF_ATTRIBUTE_MISMATCH;
       inlinable = false;
     }
+  else if (callee->externally_visible 
+	   && flag_inline_only_static) 
+    {
+      e->inline_failed = CIF_FUNCTION_EXTERN;
+      inlinable = false;
+    }
   if (!inlinable && report)
     report_inline_failed_reason (e);
   return inlinable;
diff --git a/gcc/testsuite/gcc.dg/inline_only_static.c b/gcc/testsuite/gcc.dg/inline_only_static.c
new file mode 100644
index 0000000..70fd36c
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/inline_only_static.c
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -finline-only-static -fdump-tree-einline" } */
+
+extern int sum, n, m;
+
+int foo (int a)
+{
+  return a + n;
+}
+
+static int bar (int b)
+{
+  return b * m;
+}
+
+int main()
+{
+  sum = foo (m) + bar (n); 
+  return 0;
+}
+
+/* { dg-final { scan-tree-dump "not inlinable: main/2 -> foo/0, function is external visible when the user requests only inlining static"  "einline" } } */
-- 
1.9.1

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

[Martin Sebor]

On 09/18/2018 12:58 PM, Qing Zhao wrote:
> Hi,
>
> this is the 3rd version of the patch, the major change is to address Andrew’s concern on the documentation part.
>
> I updated the documentation of this option as following:
>
> '-finline-only-static'
>      By default, GCC inlines functions without considering whether they
>      are static or not.  This flag guides inliner to only inline static
>      functions.  This option has any effect only when inlining itself is
>      turned on by the -finline-functions or -finline-small-fiunctions.
>
>      Off by default.
>
> all other changes keep the same as version 2.
>
> please take a look again. and let me know any comment and suggestion.

Just a few minor spelling issues:

>
> thanks.
>
> Qing
>
> gcc/ChangeLog
>
> +2018-09-18  Qing Zhao  <qing.zhao@oracle.com>
> +
> +	* cif-code.def (FUNCTION_EXTERN): New CIFCODE.
> +	* common.opt (-finline-only-static): New option.
> +	* doc/invoke.texi: Document -finline-only-static.
> +	* ipa-inline.c (can_inline_edge_p): Control inlining based on
> +	function's visibility.

Probably "linkage" would be a more fitting term here.

>
> gcc/testsuite/ChangeLog
>
> +2018-09-18  Qing Zhao  <qing.zhao@oracle.com>
> +
> +	* gcc.dg/inline_only_static.c: New test.
> +


diff --git a/gcc/cif-code.def b/gcc/cif-code.def
index 19a7621..64b2b1a 100644
--- a/gcc/cif-code.def
+++ b/gcc/cif-code.def
@@ -132,6 +132,12 @@
  DEFCIFCODE(USES_COMDAT_LOCAL, CIF_FINAL_ERROR,
  DEFCIFCODE(ATTRIBUTE_MISMATCH, CIF_FINAL_ERROR,
  	   N_("function attribute mismatch"))

+/* We can't inline because the user requests only inlining static 
function
+   but the function is external visible.  */

I suspect you meant: "only static functions" (plural) and
"the function has external linkage" (as defined in the C and
C++ standards).

+DEFCIFCODE(FUNCTION_EXTERN, CIF_FINAL_ERROR,
+	   N_("function is external visible when the user requests only"
+	      " inlining static"))
+

Here as well: either "function has external linkage" or "function
is extern."

=======================================
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index ec12711..b6b0db5 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@ -8066,6 +8067,15 @@
  having large chains of nested wrapper functions.

  Enabled by default.

+@item -finline-only-static
+@opindex finline-only-static
+By default, GCC inlines functions without considering whether they are 
static
+or not. This flag guides inliner to only inline static functions.

Guides "the inliner" (missing article).

+This option has any effect only when inlining itself is turned on by the
+-finline-functions or -finline-small-fiunctions.

"by the -f... options."  (Missing "options") and
-finline-small-functions (note the spelling of functions).

+
+Off by default.

I think the customary way to word it is: "Disabled by default."
or "The finline-only-static option/flag is disabled/off by default"

Martin

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

[Qing Zhao]

thanks, Martin.

> On Sep 18, 2018, at 5:26 PM, Martin Sebor <msebor@gmail.com> wrote:
>> 
>> gcc/ChangeLog
>> 
>> +2018-09-18  Qing Zhao  <qing.zhao@oracle.com <mailto:qing.zhao@oracle.com>>
>> +
>> +	* cif-code.def (FUNCTION_EXTERN): New CIFCODE.
>> +	* common.opt (-finline-only-static): New option.
>> +	* doc/invoke.texi: Document -finline-only-static.
>> +	* ipa-inline.c (can_inline_edge_p): Control inlining based on
>> +	function's visibility.
> 
> Probably "linkage" would be a more fitting term here.
Okay.

> 
>> 
>> gcc/testsuite/ChangeLog
>> 
>> +2018-09-18  Qing Zhao  <qing.zhao@oracle.com <mailto:qing.zhao@oracle.com>>
>> +
>> +	* gcc.dg/inline_only_static.c: New test.
>> +
> 
> 
> diff --git a/gcc/cif-code.def b/gcc/cif-code.def
> index 19a7621..64b2b1a 100644
> --- a/gcc/cif-code.def
> +++ b/gcc/cif-code.def
> @@ -132,6 +132,12 @@
> DEFCIFCODE(USES_COMDAT_LOCAL, CIF_FINAL_ERROR,
> DEFCIFCODE(ATTRIBUTE_MISMATCH, CIF_FINAL_ERROR,
> 	   N_("function attribute mismatch"))
> 
> +/* We can't inline because the user requests only inlining static function
> +   but the function is external visible.  */
> 
> I suspect you meant: "only static functions" (plural) and
> "the function has external linkage" (as defined in the C and
> C++ standards).
Okay.

> 
> +DEFCIFCODE(FUNCTION_EXTERN, CIF_FINAL_ERROR,
> +	   N_("function is external visible when the user requests only"
> +	      " inlining static"))
> +
> 
> Here as well: either "function has external linkage" or "function
> is extern.”
Okay.
> 
> =======================================
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index ec12711..b6b0db5 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @ -8066,6 +8067,15 @@
> having large chains of nested wrapper functions.
> 
> Enabled by default.
> 
> +@item -finline-only-static
> +@opindex finline-only-static
> +By default, GCC inlines functions without considering whether they are static
> +or not. This flag guides inliner to only inline static functions.
> 
> Guides "the inliner" (missing article).
Okay.

> 
> +This option has any effect only when inlining itself is turned on by the
> +-finline-functions or -finline-small-fiunctions.
> 
> "by the -f... options."  (Missing "options") and
> -finline-small-functions (note the spelling of functions).

Okay.
> 
> +
> +Off by default.
> 
> I think the customary way to word it is: "Disabled by default."
> or "The finline-only-static option/flag is disabled/off by default”

Okay.

Qing
> 
> Martin

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

[Qing Zhao]

[-- Attachment #1: Type: text/plain, Size: 651 bytes --]

Hi, this is the 4th version of the patch.

mainly address Martin’s comments on some spelling issues.

I have tested the patch on both x86 and aarch64, no issue.

Okay for commit?

thanks.

Qing.

gcc/ChangeLog

+2018-09-20  Qing Zhao  <qing.zhao@oracle.com>
+
+	* cif-code.def (FUNCTION_EXTERN): New CIFCODE.
+	* common.opt (-finline-only-static): New option.
+	* doc/invoke.texi: Document -finline-only-static.
+	* ipa-inline.c (can_inline_edge_p): Control inlining based on
+	function's linkage. 

gcc/testsuite/ChangeLog

+2018-09-20  Qing Zhao  <qing.zhao@oracle.com>
+
+	* gcc.dg/inline_only_static.c: New test.
+


[-- Attachment #2: New-inline-only-static.patch --]
[-- Type: application/octet-stream, Size: 4015 bytes --]

---
 gcc/cif-code.def                          |  6 ++++++
 gcc/common.opt                            |  4 ++++
 gcc/doc/invoke.texi                       | 12 +++++++++++-
 gcc/ipa-inline.c                          |  6 ++++++
 gcc/testsuite/gcc.dg/inline-only-static.c | 22 ++++++++++++++++++++++
 5 files changed, 49 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/inline-only-static.c

diff --git a/gcc/cif-code.def b/gcc/cif-code.def
index 19a7621..4eb530e 100644
--- a/gcc/cif-code.def
+++ b/gcc/cif-code.def
@@ -132,6 +132,12 @@ DEFCIFCODE(USES_COMDAT_LOCAL, CIF_FINAL_ERROR,
 DEFCIFCODE(ATTRIBUTE_MISMATCH, CIF_FINAL_ERROR,
 	   N_("function attribute mismatch"))
 
+/* We can't inline because the user requests only static functions 
+   but the function has external linkage.  */
+DEFCIFCODE(FUNCTION_EXTERN, CIF_FINAL_ERROR,
+	   N_("function has external linkage when the user requests only"
+	      " inlining static"))
+
 /* We proved that the call is unreachable.  */
 DEFCIFCODE(UNREACHABLE, CIF_FINAL_ERROR,
 	   N_("unreachable"))
diff --git a/gcc/common.opt b/gcc/common.opt
index ef6a630..9c66a56 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1633,6 +1633,10 @@ finline-atomics
 Common Report Var(flag_inline_atomics) Init(1) Optimization
 Inline __atomic operations when a lock free instruction sequence is available.
 
+finline-only-static
+Common RejectNegative Var(flag_inline_only_static) Init(0) 
+Inline functions only when they are declared \"static\". 
+
 fcf-protection
 Common RejectNegative Alias(fcf-protection=,full)
 
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index ec12711..dc6ece1 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -407,7 +407,8 @@ Objective-C and Objective-C++ Dialects}.
 -fgcse-sm  -fhoist-adjacent-loads  -fif-conversion @gol
 -fif-conversion2  -findirect-inlining @gol
 -finline-functions  -finline-functions-called-once  -finline-limit=@var{n} @gol
--finline-small-functions  -fipa-cp  -fipa-cp-clone @gol
+-finline-only-static @gol
+-finline-small-functions -fipa-cp  -fipa-cp-clone @gol
 -fipa-bit-cp -fipa-vrp @gol
 -fipa-pta  -fipa-profile  -fipa-pure-const  -fipa-reference  -fipa-icf @gol
 -fira-algorithm=@var{algorithm} @gol
@@ -8066,6 +8067,15 @@ having large chains of nested wrapper functions.
 
 Enabled by default.
 
+@item -finline-only-static
+@opindex finline-only-static
+By default, GCC inlines functions without considering whether they are static 
+or not. This flag guides the inliner to only inline static functions. 
+This option has any effect only when inlining itself is turned on by the 
+-finline-functions or -finline-small-functions options. 
+
+Disabled by default.
+
 @item -fipa-sra
 @opindex fipa-sra
 Perform interprocedural scalar replacement of aggregates, removal of
diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
index 0257885..f432243 100644
--- a/gcc/ipa-inline.c
+++ b/gcc/ipa-inline.c
@@ -376,6 +376,12 @@ can_inline_edge_p (struct cgraph_edge *e, bool report,
       e->inline_failed = CIF_ATTRIBUTE_MISMATCH;
       inlinable = false;
     }
+  else if (callee->externally_visible 
+	   && flag_inline_only_static) 
+    {
+      e->inline_failed = CIF_FUNCTION_EXTERN;
+      inlinable = false;
+    }
   if (!inlinable && report)
     report_inline_failed_reason (e);
   return inlinable;
diff --git a/gcc/testsuite/gcc.dg/inline-only-static.c b/gcc/testsuite/gcc.dg/inline-only-static.c
new file mode 100644
index 0000000..b655a49
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/inline-only-static.c
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -finline-only-static -fdump-tree-einline" } */
+
+extern int sum, n, m;
+
+int foo (int a)
+{
+  return a + n;
+}
+
+static int bar (int b)
+{
+  return b * m;
+}
+
+int main()
+{
+  sum = foo (m) + bar (n); 
+  return 0;
+}
+
+/* { dg-final { scan-tree-dump "not inlinable: main/2 -> foo/0, function has external linkage when the user requests only inlining static"  "einline" } } */
-- 
1.9.1

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

[Qing Zhao]

Hi, 

I’d like to ping the following patch.

https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01238.html <https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01238.html>

Thanks.

Qing

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

[Alexander Monakov]

On Fri, 21 Sep 2018, Qing Zhao wrote:
> +2018-09-20  Qing Zhao  <qing.zhao@oracle.com>
> +
> +	* cif-code.def (FUNCTION_EXTERN): New CIFCODE.
> +	* common.opt (-finline-only-static): New option.
> +	* doc/invoke.texi: Document -finline-only-static.
> +	* ipa-inline.c (can_inline_edge_p): Control inlining based on
> +	function's linkage. 

Note, I am not a reviewer.

In my opinion, there's a problem with the patch that it looks like an ad-hoc,
incomplete solution. You said you need this change to help with building
livepatching-capable kernels, but it's not clear what exactly the issue with
inlining non-static functions is. Can you describe how the workflow looks like
so code duplication due to inlining static functions is not an issue, but
inlining non-static functions is a problem? Does using existing
-fno-inline-functions flag achieve something useful for your usecase?

Please always make it clear what problem the patch is intended to solve and help
reviewers see the connection between the problem and your solution. Look how the
"XY problem" effect applies partially in this situation.

https://en.wikipedia.org/wiki/XY_problem
http://xyproblem.info/

Alexander

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

[Paolo Carlini]

Hi,

On 9/26/18 1:12 PM, Alexander Monakov wrote:
> On Fri, 21 Sep 2018, Qing Zhao wrote:
>> +2018-09-20  Qing Zhao  <qing.zhao@oracle.com>
>> +
>> +	* cif-code.def (FUNCTION_EXTERN): New CIFCODE.
>> +	* common.opt (-finline-only-static): New option.
>> +	* doc/invoke.texi: Document -finline-only-static.
>> +	* ipa-inline.c (can_inline_edge_p): Control inlining based on
>> +	function's linkage.
> Note, I am not a reviewer.
>
> In my opinion, there's a problem with the patch that it looks like an ad-hoc,
> incomplete solution.

It is not. Actually, I don't understand why we are raising this sort of 
issue now, after so many messages, like, for example Jeff's, which 
should have fully clarified the rationale.

Paolo.

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

[Qing Zhao]

Alexander,

thanks for the questions.

Yes, we had some discussion on the questions you raised during the review of the initial patch back to 9/11/2018.
please take a look at those discussions at:

https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00549.html <https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00549.html>
https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00787.html <https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00787.html>

and let me know if those discussion still does not answer your questions.

Qing

> On Sep 26, 2018, at 6:12 AM, Alexander Monakov <amonakov@ispras.ru> wrote:
> 
> On Fri, 21 Sep 2018, Qing Zhao wrote:
>> +2018-09-20  Qing Zhao  <qing.zhao@oracle.com>
>> +
>> +	* cif-code.def (FUNCTION_EXTERN): New CIFCODE.
>> +	* common.opt (-finline-only-static): New option.
>> +	* doc/invoke.texi: Document -finline-only-static.
>> +	* ipa-inline.c (can_inline_edge_p): Control inlining based on
>> +	function's linkage. 
> 
> Note, I am not a reviewer.
> 
> In my opinion, there's a problem with the patch that it looks like an ad-hoc,
> incomplete solution. You said you need this change to help with building
> livepatching-capable kernels, but it's not clear what exactly the issue with
> inlining non-static functions is. Can you describe how the workflow looks like
> so code duplication due to inlining static functions is not an issue, but
> inlining non-static functions is a problem? Does using existing
> -fno-inline-functions flag achieve something useful for your usecase?
> 
> Please always make it clear what problem the patch is intended to solve and help
> reviewers see the connection between the problem and your solution. Look how the
> "XY problem" effect applies partially in this situation.
> 
> https://en.wikipedia.org/wiki/XY_problem
> http://xyproblem.info/
> 
> Alexander

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

[Alexander Monakov]

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 initial patch back to 9/11/2018.
> please take a look at those discussions at:
> 
> https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00549.html <https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00549.html>
> https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00787.html <https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00787.html>
> 
> and let me know if those discussion still does not answer your questions.

Thank you. Yes, it is still unclear to me why restricting inlining to static
functions noticeably helps in your case. Is it because you build the kernel
with LTO? Otherwise effects from inlining are limited to one compilation unit,
except for functions defined in headers. But for those, the kernel
uses 'static inline' anyway, so the patch wouldn't change anything.

If the original issue is that inlining duplicates code, wouldn't it be better
solved by a switch that instructs inlining heuristics to inline as if for -Os,
without enabling -Os for other passes?

Alexander

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

[Qing Zhao]

> On Sep 26, 2018, at 10:16 AM, Alexander Monakov <amonakov@ispras.ru> 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 initial patch back to 9/11/2018.
>> please take a look at those discussions at:
>> 
>> https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00549.html <https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00549.html>
>> https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00787.html <https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00787.html>
>> 
>> and let me know if those discussion still does not answer your questions.
> 
> Thank you. Yes, it is still unclear to me why restricting inlining to static
> functions noticeably helps in your case. Is it because you build the kernel
> with LTO? Otherwise effects from inlining are limited to one compilation unit,
> except for functions defined in headers. But for those, the kernel
> uses 'static inline' anyway, so the patch wouldn't change anything.

The request is for application developers who want to use gcc's online
   patching feature.

Today, developers can turn off inlining and deliver just the patched routine.  They
   can also allow all inlining and deliver the patched routine and all the routines
   that the patched routine was inlined into.

completely turning off inlining will sacrifice too much run-time performance. completely
enable inlining, on the other hand, will have the potential issues with code size, complexity and
debuggability for the online patching.

the proposed option provides a compromised solution for the above issues. and enable more
developers to utilize gcc’s online patching feature.

hope this is helpful.

Qing


> If the original issue is that inlining duplicates code, wouldn't it be better
> solved by a switch that instructs inlining heuristics to inline as if for -Os,
> without enabling -Os for other passes?
> 
> Alexander

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

[Alexander Monakov]

[-- Attachment #1: Type: text/plain, Size: 1177 bytes --]

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 deliver just the patched routine.  They
>    can also allow all inlining and deliver the patched routine and all the routines
>    that the patched routine was inlined into.
> 
> completely turning off inlining will sacrifice too much run-time performance. completely
> enable inlining, on the other hand, will have the potential issues with code size, complexity and
> debuggability for the online patching.
> 
> the proposed option provides a compromised solution for the above issues. and enable more
> developers to utilize gcc’s online patching feature.

From this explanation it sounds to me that what you really need is -Os-like
behavior for IPA passes, without enabling -Os for gimple/rtl passes, as I
mentioned in my previous email. Honza, how does that sound?

> > If the original issue is that inlining duplicates code, wouldn't it be better
> > solved by a switch that instructs inlining heuristics to inline as if for -Os,
> > without enabling -Os for other passes?

Alexander

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

[Qing Zhao]

> On Sep 26, 2018, at 6:07 PM, Alexander Monakov <amonakov@ispras.ru> 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 deliver just the patched routine.  They
>>   can also allow all inlining and deliver the patched routine and all the routines
>>   that the patched routine was inlined into.
>> 
>> completely turning off inlining will sacrifice too much run-time performance. completely
>> enable inlining, on the other hand, will have the potential issues with code size, complexity and
>> debuggability for the online patching.
>> 
>> the proposed option provides a compromised solution for the above issues. and enable more
>> developers to utilize gcc’s online patching feature.
> 
> From this explanation it sounds to me that what you really need is -Os-like
> behavior for IPA passes, without enabling -Os for gimple/rtl passes, as I
> mentioned in my previous email. Honza, how does that sound?

I don’t think a -Os-like option will do the job.

As Jeff already mentioned in a very previous email:

“Presumably one of the cases where this capability is really helpful is
things like ksplice.   If you have a function with global scope that has
been potentially inlined, then it's a lot harder track down those
inlining points at DTRT.

We ran into this internally when looking at hot patching some of the
spinlock code in the kernel.  It would have been real helpful if the
kernel had been compiled with this kind of option :-)

So conceptually I can see value in this kind of option.
“

so, specially control inlining on static/global will be helpful to online patch.

Qing

> 
>>> If the original issue is that inlining duplicates code, wouldn't it be better
>>> solved by a switch that instructs inlining heuristics to inline as if for -Os,
>>> without enabling -Os for other passes?
> 
> Alexander

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

[Richard Biener]

[-- Attachment #1: Type: text/plain, Size: 3305 bytes --]

On Wed, 26 Sep 2018, Qing Zhao wrote:

> 
> > On Sep 26, 2018, at 6:07 PM, Alexander Monakov <amonakov@ispras.ru> 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 deliver just the patched routine.  They
> >>   can also allow all inlining and deliver the patched routine and all the routines
> >>   that the patched routine was inlined into.
> >> 
> >> completely turning off inlining will sacrifice too much run-time performance. completely
> >> enable inlining, on the other hand, will have the potential issues with code size, complexity and
> >> debuggability for the online patching.
> >> 
> >> the proposed option provides a compromised solution for the above issues. and enable more
> >> developers to utilize gcc’s online patching feature.
> > 
> > From this explanation it sounds to me that what you really need is -Os-like
> > behavior for IPA passes, without enabling -Os for gimple/rtl passes, as I
> > mentioned in my previous email. Honza, how does that sound?
> 
> I don’t think a -Os-like option will do the job.
> 
> As Jeff already mentioned in a very previous email:
> 
> “Presumably one of the cases where this capability is really helpful is
> things like ksplice.   If you have a function with global scope that has
> been potentially inlined, then it's a lot harder track down those
> inlining points at DTRT.
> 
> We ran into this internally when looking at hot patching some of the
> spinlock code in the kernel.  It would have been real helpful if the
> kernel had been compiled with this kind of option :-)
> 
> So conceptually I can see value in this kind of option.
> “
> 
> so, specially control inlining on static/global will be helpful to online patch.

But as Honza said this gets you only sofar.  IIRC for our kernel 
livepatching we turn off most IPA passes because while we can "easily"
figure what and where things were inlined spotting the effects of
IPA analysis and transform is almost impossible.

So there's two parts of the knob - one is to make the live-patch size
not explode (do less inlining where it doesn't hurt performance - that
eventually also applies to static functions called once inlining!).
The other is to make it possible to conservatively compute the set
of functions you have to replace (the set of functions that are
affected by a patch).

Having an option to _that_ effect might indeed be useful (to avoid
people chasing all the flags they need to disable).  So shouldn't this
be a -fease-live-patching option rather that -finline-only-static
which doesn't really capture the intention nor the effect?

That is, -fease-live-patching would guarantee that if you source-patch
function X then, if you replace all functions which debuginfo tells you
X was inlined to, the result will be semantically equivalent with
replacing the whole program?  We might even add sth like
-fpatch-symbol-list=FOO,BAR that outputs a list of symbols into BAR
that are affected this way when functions FOO are changed (you
run that on unpatched code of course).  Or we add sth to the
cgraph dumpfile that for each function lists the set of symbols
it was affected by.

Thanks,
Richard.

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

[Qing Zhao]

> On Sep 27, 2018, at 2:45 AM, Richard Biener <rguenther@suse.de> wrote:
> 
> On Wed, 26 Sep 2018, Qing Zhao wrote:
> 
>> 
>>> On Sep 26, 2018, at 6:07 PM, Alexander Monakov <amonakov@ispras.ru> 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 deliver just the patched routine.  They
>>>>  can also allow all inlining and deliver the patched routine and all the routines
>>>>  that the patched routine was inlined into.
>>>> 
>>>> completely turning off inlining will sacrifice too much run-time performance. completely
>>>> enable inlining, on the other hand, will have the potential issues with code size, complexity and
>>>> debuggability for the online patching.
>>>> 
>>>> the proposed option provides a compromised solution for the above issues. and enable more
>>>> developers to utilize gcc’s online patching feature.
>>> 
>>> From this explanation it sounds to me that what you really need is -Os-like
>>> behavior for IPA passes, without enabling -Os for gimple/rtl passes, as I
>>> mentioned in my previous email. Honza, how does that sound?
>> 
>> I don’t think a -Os-like option will do the job.
>> 
>> As Jeff already mentioned in a very previous email:
>> 
>> “Presumably one of the cases where this capability is really helpful is
>> things like ksplice.   If you have a function with global scope that has
>> been potentially inlined, then it's a lot harder track down those
>> inlining points at DTRT.
>> 
>> We ran into this internally when looking at hot patching some of the
>> spinlock code in the kernel.  It would have been real helpful if the
>> kernel had been compiled with this kind of option :-)
>> 
>> So conceptually I can see value in this kind of option.
>> “
>> 
>> so, specially control inlining on static/global will be helpful to online patch.
> 
> But as Honza said this gets you only sofar.  IIRC for our kernel 
> livepatching we turn off most IPA passes because while we can "easily"
> figure what and where things were inlined spotting the effects of
> IPA analysis and transform is almost impossible.
> 
> So there's two parts of the knob - one is to make the live-patch size
> not explode (do less inlining where it doesn't hurt performance - that
> eventually also applies to static functions called once inlining!).

Yes, limit additional unnecessary inlining might be better/

> The other is to make it possible to conservatively compute the set
> of functions you have to replace (the set of functions that are
> affected by a patch).
right.
> 
> Having an option to _that_ effect might indeed be useful (to avoid
> people chasing all the flags they need to disable).  So shouldn't this
> be a -fease-live-patching option rather that -finline-only-static
> which doesn't really capture the intention nor the effect?
Yes, if we can have -fease-live-patching, that will be even better for the live patch purpose.

> 
> That is, -fease-live-patching would guarantee that if you source-patch
> function X then, if you replace all functions which debuginfo tells you
> X was inlined to, the result will be semantically equivalent with
> replacing the whole program?  

Okay.

> We might even add sth like
> -fpatch-symbol-list=FOO,BAR that outputs a list of symbols into BAR
> that are affected this way when functions FOO are changed (you
> run that on unpatched code of course).  Or we add sth to the
> cgraph dumpfile that for each function lists the set of symbols
> it was affected by.

Yes, this option might be also helpful for livepatching. we can do it at the next step.

Qing
> 
> Thanks,
> Richard.

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

[Alexander Monakov]

[-- Attachment #1: Type: text/plain, Size: 1043 bytes --]

On Wed, 26 Sep 2018, Qing Zhao wrote:
> I don’t think a -Os-like option will do the job.
> 
> As Jeff already mentioned in a very previous email:
> 
> “Presumably one of the cases where this capability is really helpful is
> things like ksplice.   If you have a function with global scope that has
> been potentially inlined, then it's a lot harder track down those
> inlining points at DTRT.
> 
> We ran into this internally when looking at hot patching some of the
> spinlock code in the kernel.  It would have been real helpful if the
> kernel had been compiled with this kind of option :-)
> 
> So conceptually I can see value in this kind of option.
> “
> 
> so, specially control inlining on static/global will be helpful to online patch.

In addition to what Richard said, I don't follow this reasoning. The issue with
spinlock functions is that many of them are defined in header files and get
inlined everywhere, correct? But such functions are all 'static inline', so this
patch wouldn't affect them at all.

Alexander

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

[Jan Hubicka]

> 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 deliver just the patched routine.  They
> >    can also allow all inlining and deliver the patched routine and all the routines
> >    that the patched routine was inlined into.
> > 
> > completely turning off inlining will sacrifice too much run-time performance. completely
> > enable inlining, on the other hand, will have the potential issues with code size, complexity and
> > debuggability for the online patching.
> > 
> > the proposed option provides a compromised solution for the above issues. and enable more
> > developers to utilize gcc’s online patching feature.
> 
> From this explanation it sounds to me that what you really need is -Os-like
> behavior for IPA passes, without enabling -Os for gimple/rtl passes, as I
> mentioned in my previous email. Honza, how does that sound?

How -Os is related? We will still do things like inlining or cloning of functions
if we expect code size to decrease (that may happen if arguments become dead)

Honza
> 
> > > If the original issue is that inlining duplicates code, wouldn't it be better
> > > solved by a switch that instructs inlining heuristics to inline as if for -Os,
> > > without enabling -Os for other passes?
> 
> Alexander

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

[Richard Biener]

[-- Attachment #1: Type: text/plain, Size: 1403 bytes --]

On Thu, 27 Sep 2018, Jan Hubicka 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 deliver just the patched routine.  They
> > >    can also allow all inlining and deliver the patched routine and all the routines
> > >    that the patched routine was inlined into.
> > > 
> > > completely turning off inlining will sacrifice too much run-time performance. completely
> > > enable inlining, on the other hand, will have the potential issues with code size, complexity and
> > > debuggability for the online patching.
> > > 
> > > the proposed option provides a compromised solution for the above issues. and enable more
> > > developers to utilize gcc’s online patching feature.
> > 
> > From this explanation it sounds to me that what you really need is -Os-like
> > behavior for IPA passes, without enabling -Os for gimple/rtl passes, as I
> > mentioned in my previous email. Honza, how does that sound?
> 
> How -Os is related? We will still do things like inlining or cloning of functions
> if we expect code size to decrease (that may happen if arguments become dead)

Yeah, I was suggesting -fno-inline-small-functions which would get you
to do it the Linus-way (do-what-I-say) and only inline 'inline' declared
functions.

Richard.

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

[Jason Merrill]

On Fri, Sep 21, 2018 at 11:12 AM, Qing Zhao <qing.zhao@oracle.com> wrote:
> Hi, this is the 4th version of the patch.
>
> mainly address Martin’s comments on some spelling issues.
>
> I have tested the patch on both x86 and aarch64, no issue.
>
> Okay for commit?
>
> thanks.
>
> Qing.
>
> gcc/ChangeLog
>
> +2018-09-20  Qing Zhao  <qing.zhao@oracle.com>
> +
> +       * cif-code.def (FUNCTION_EXTERN): New CIFCODE.
> +       * common.opt (-finline-only-static): New option.
> +       * doc/invoke.texi: Document -finline-only-static.
> +       * ipa-inline.c (can_inline_edge_p): Control inlining based on
> +       function's linkage.

I would suggest "internal" rather than "static" in general.  So

+    N_("function has external linkage when the user requests only"
+       " inlining functions with internal linkage"))

+Inline functions only if they have internal linkage.

+@item -finline-only-internal
+@opindex finline-only-internal
+By default, GCC inlines functions without considering their linkage.
+This flag guides the inliner to only inline functions with internal linkage.
+This option has any effect only when inlining itself is turned on by the
+-finline-functions or -finline-small-functions options.

This should also mention whether it applies to functions explicitly
declared inline; I assume it does not.

Jason

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

[Richard Biener]

[-- Attachment #1: Type: text/plain, Size: 2045 bytes --]

On Wed, 26 Sep 2018, Jason Merrill wrote:

> On Fri, Sep 21, 2018 at 11:12 AM, Qing Zhao <qing.zhao@oracle.com> wrote:
> > Hi, this is the 4th version of the patch.
> >
> > mainly address Martin’s comments on some spelling issues.
> >
> > I have tested the patch on both x86 and aarch64, no issue.
> >
> > Okay for commit?
> >
> > thanks.
> >
> > Qing.
> >
> > gcc/ChangeLog
> >
> > +2018-09-20  Qing Zhao  <qing.zhao@oracle.com>
> > +
> > +       * cif-code.def (FUNCTION_EXTERN): New CIFCODE.
> > +       * common.opt (-finline-only-static): New option.
> > +       * doc/invoke.texi: Document -finline-only-static.
> > +       * ipa-inline.c (can_inline_edge_p): Control inlining based on
> > +       function's linkage.
> 
> I would suggest "internal" rather than "static" in general.  So
> 
> +    N_("function has external linkage when the user requests only"
> +       " inlining functions with internal linkage"))
> 
> +Inline functions only if they have internal linkage.
> 
> +@item -finline-only-internal
> +@opindex finline-only-internal
> +By default, GCC inlines functions without considering their linkage.
> +This flag guides the inliner to only inline functions with internal linkage.
> +This option has any effect only when inlining itself is turned on by the
> +-finline-functions or -finline-small-functions options.
> 
> This should also mention whether it applies to functions explicitly
> declared inline; I assume it does not.

IIRC he explicitely wanted 'static' not 'hidden' linkage.  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 at depending on what we intend to do.

What about 'static' functions with their address taken?

Note you shouldn't look at individual cgraph_node fields but use
some of the accessors with more well-constrained semantics.
Why are you not simply checking !TREE_PUBLIC?

Honza might be able to suggest one.

Richard.

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

[Jason Merrill]

On Wed, Sep 26, 2018 at 9:24 AM, Richard Biener <rguenther@suse.de> wrote:
> IIRC he explicitely wanted 'static' not 'hidden' linkage.  Not sure
> what 'internal' would mean in this context.

I mean internal linkage as in the C and C++ standards.

Jason

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

[Jeff Law]

On 9/26/18 7:38 AM, Jason Merrill wrote:
> On Wed, Sep 26, 2018 at 9:24 AM, Richard Biener <rguenther@suse.de> wrote:
>> IIRC he explicitely wanted 'static' not 'hidden' linkage.  Not sure
>> what 'internal' would mean in this context.
> 
> I mean internal linkage as in the C and C++ standards.
Since this is primarily for kernel hot patching, I think we're looking
to restrict inlining to functions that have visibility limited to a
compilation unit.

Qing, can you confirm that either way?

Jeff

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

[Jason Merrill]

On Wed, Sep 26, 2018 at 10:45 AM, Jeff Law <law@redhat.com> wrote:
> On 9/26/18 7:38 AM, Jason Merrill wrote:
>> On Wed, Sep 26, 2018 at 9:24 AM, Richard Biener <rguenther@suse.de> wrote:
>>> IIRC he explicitely wanted 'static' not 'hidden' linkage.  Not sure
>>> what 'internal' would mean in this context.
>>
>> I mean internal linkage as in the C and C++ standards.

> Since this is primarily for kernel hot patching, I think we're looking
> to restrict inlining to functions that have visibility limited to a
> compilation unit.

Right, which is internal linkage.

C11: "Within one translation unit, each declaration of an identifier
with internal linkage denotes the same object or function."
C++17: "When a name has internal linkage, the entity it denotes can be
referred to by names from other scopes in the same translation unit."

Or perhaps we want to say "not external linkage", i.e. !TREE_PUBLIC as
richi suggested.

Jason

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

[Jan Hubicka]

> On Wed, Sep 26, 2018 at 10:45 AM, Jeff Law <law@redhat.com> wrote:
> > On 9/26/18 7:38 AM, Jason Merrill wrote:
> >> On Wed, Sep 26, 2018 at 9:24 AM, Richard Biener <rguenther@suse.de> wrote:
> >>> IIRC he explicitely wanted 'static' not 'hidden' linkage.  Not sure
> >>> what 'internal' would mean in this context.
> >>
> >> I mean internal linkage as in the C and C++ standards.
> 
> > Since this is primarily for kernel hot patching, I think we're looking
> > to restrict inlining to functions that have visibility limited to a
> > compilation unit.
> 
> Right, which is internal linkage.
> 
> C11: "Within one translation unit, each declaration of an identifier
> with internal linkage denotes the same object or function."
> C++17: "When a name has internal linkage, the entity it denotes can be
> referred to by names from other scopes in the same translation unit."
> 
> Or perhaps we want to say "not external linkage", i.e. !TREE_PUBLIC as
> richi suggested.

I am not quite sure if we can relate visibility flags we have at this stage
to visibility in source languge in very coherent way.  They change a lot with
LTO and we may want to make this option incompatible with LTO, but even w/o
we can turn function static that previously wasn't.

For example comdat that was cloned by IPA-SRA. See can_be_local_p and
comdat_can_be_unshared_p predicates.  Similar problem happens to clones created
by ipa-cp.

I guess we want to disable localization and cloning in this case as well.
I wonder what else.

Honza

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

[Qing Zhao]

> On Sep 26, 2018, at 10:06 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
> 
>> On Wed, Sep 26, 2018 at 10:45 AM, Jeff Law <law@redhat.com> wrote:
>>> On 9/26/18 7:38 AM, Jason Merrill wrote:
>>>> On Wed, Sep 26, 2018 at 9:24 AM, Richard Biener <rguenther@suse.de> wrote:
>>>>> IIRC he explicitely wanted 'static' not 'hidden' linkage.  Not sure
>>>>> what 'internal' would mean in this context.
>>>> 
>>>> I mean internal linkage as in the C and C++ standards.
>> 
>>> Since this is primarily for kernel hot patching, I think we're looking
>>> to restrict inlining to functions that have visibility limited to a
>>> compilation unit.
>> 
>> Right, which is internal linkage.
>> 
>> C11: "Within one translation unit, each declaration of an identifier
>> with internal linkage denotes the same object or function."
>> C++17: "When a name has internal linkage, the entity it denotes can be
>> referred to by names from other scopes in the same translation unit."
>> 
>> Or perhaps we want to say "not external linkage", i.e. !TREE_PUBLIC as
>> richi suggested.
> 
> I am not quite sure if we can relate visibility flags we have at this stage
> to visibility in source languge in very coherent way.  They change a lot with
> LTO and we may want to make this option incompatible with LTO, but even w/o
> we can turn function static that previously wasn’t.

Looks like both LTO and whole_program need to be made incompatible with -finline-only-static. 
from my study of the function “cgraph_externally_visible_p”, comdat functions can ONLY be turned into
static when either “in_lto_p” or “whole_program” is true. 


> For example comdat that was cloned by IPA-SRA. See can_be_local_p and
> comdat_can_be_unshared_p predicates.  Similar problem happens to clones created
> by ipa-cp.
> 
> I guess we want to disable localization and cloning in this case as well.
> I wonder what else.

Yes, I think we should make -finline-only-static incompatible with cloning and tree-sra too.

Qing
> 
> Honza

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

[Jan Hubicka]

> 
> > On Sep 26, 2018, at 10:06 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
> > 
> >> On Wed, Sep 26, 2018 at 10:45 AM, Jeff Law <law@redhat.com> wrote:
> >>> On 9/26/18 7:38 AM, Jason Merrill wrote:
> >>>> On Wed, Sep 26, 2018 at 9:24 AM, Richard Biener <rguenther@suse.de> wrote:
> >>>>> IIRC he explicitely wanted 'static' not 'hidden' linkage.  Not sure
> >>>>> what 'internal' would mean in this context.
> >>>> 
> >>>> I mean internal linkage as in the C and C++ standards.
> >> 
> >>> Since this is primarily for kernel hot patching, I think we're looking
> >>> to restrict inlining to functions that have visibility limited to a
> >>> compilation unit.
> >> 
> >> Right, which is internal linkage.
> >> 
> >> C11: "Within one translation unit, each declaration of an identifier
> >> with internal linkage denotes the same object or function."
> >> C++17: "When a name has internal linkage, the entity it denotes can be
> >> referred to by names from other scopes in the same translation unit."
> >> 
> >> Or perhaps we want to say "not external linkage", i.e. !TREE_PUBLIC as
> >> richi suggested.
> > 
> > I am not quite sure if we can relate visibility flags we have at this stage
> > to visibility in source languge in very coherent way.  They change a lot with
> > LTO and we may want to make this option incompatible with LTO, but even w/o
> > we can turn function static that previously wasn’t.
> 
> Looks like both LTO and whole_program need to be made incompatible with -finline-only-static. 
> from my study of the function “cgraph_externally_visible_p”, comdat functions can ONLY be turned into
> static when either “in_lto_p” or “whole_program” is true. 

This is not quite the case, because, we can still clone them to static functions
or derive fact about their side effects (such that information if they write/read
memory, particular global var etc).  All this inter-procedural propagation
is guarded by get_availability predicate returning at least AVAILABLE.

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 other optimization will give up on these.

Honza
> 
> 
> > For example comdat that was cloned by IPA-SRA. See can_be_local_p and
> > comdat_can_be_unshared_p predicates.  Similar problem happens to clones created
> > by ipa-cp.
> > 
> > I guess we want to disable localization and cloning in this case as well.
> > I wonder what else.
> 
> Yes, I think we should make -finline-only-static incompatible with cloning and tree-sra too.
> 
> Qing
> > 
> > Honza
> 

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

[Qing Zhao]

> On Sep 26, 2018, at 12:16 PM, Jan Hubicka <hubicka@ucw.cz> wrote:
> 
>>> 
>>> On Sep 26, 2018, at 10:06 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>>> 
>>>> On Wed, Sep 26, 2018 at 10:45 AM, Jeff Law <law@redhat.com> wrote:
>>>>> On 9/26/18 7:38 AM, Jason Merrill wrote:
>>>>>> On Wed, Sep 26, 2018 at 9:24 AM, Richard Biener <rguenther@suse.de> wrote:
>>>>>>> IIRC he explicitely wanted 'static' not 'hidden' linkage.  Not sure
>>>>>>> what 'internal' would mean in this context.
>>>>>> 
>>>>>> I mean internal linkage as in the C and C++ standards.
>>>> 
>>>>> Since this is primarily for kernel hot patching, I think we're looking
>>>>> to restrict inlining to functions that have visibility limited to a
>>>>> compilation unit.
>>>> 
>>>> Right, which is internal linkage.
>>>> 
>>>> C11: "Within one translation unit, each declaration of an identifier
>>>> with internal linkage denotes the same object or function."
>>>> C++17: "When a name has internal linkage, the entity it denotes can be
>>>> referred to by names from other scopes in the same translation unit."
>>>> 
>>>> Or perhaps we want to say "not external linkage", i.e. !TREE_PUBLIC as
>>>> richi suggested.
>>> 
>>> I am not quite sure if we can relate visibility flags we have at this stage
>>> to visibility in source languge in very coherent way.  They change a lot with
>>> LTO and we may want to make this option incompatible with LTO, but even w/o
>>> we can turn function static that previously wasn’t.
>> 
>> Looks like both LTO and whole_program need to be made incompatible with -finline-only-static. 
>> from my study of the function “cgraph_externally_visible_p”, comdat functions can ONLY be turned into
>> static when either “in_lto_p” or “whole_program” is true. 
> 
> This is not quite the case, because, we can still clone them to static functions
> or derive fact about their side effects (such that information if they write/read
> memory, particular global var etc).  All this inter-procedural propagation
> is guarded by get_availability predicate returning at least AVAILABLE.

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 other optimization will give up on these.

do you suggest that to set the global function as AVAIL_INTERPOSABLE when -finline-only-static 
is present? then we should avoid all issues?

Qing


> Honza
>> 
>> 
>>> For example comdat that was cloned by IPA-SRA. See can_be_local_p and
>>> comdat_can_be_unshared_p predicates.  Similar problem happens to clones created
>>> by ipa-cp.
>>> 
>>> I guess we want to disable localization and cloning in this case as well.
>>> I wonder what else.
>> 
>> Yes, I think we should make -finline-only-static incompatible with cloning and tree-sra too.
>> 
>> Qing
>>> 
>>> Honza

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

[Jan Hubicka]

> 
> 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 other optimization will give up on these.
> 
> do you suggest that to set the global function as AVAIL_INTERPOSABLE when -finline-only-static 
> is present? then we should avoid all issues?

It seems to be reasonable direction I think, because it is what really happens
(well AVAIL_INTERPOSABLE still does not assume that the interposition will
happen at runtime, but it is an approximation and we may introduce something like
AVAIL_RUNTIME_INTERPOSABLE if there is need for better difference).
I wonder if -finline-only-static is good name for the flag though, because it
does a lot more than that.  Maybe something like -flive-patching?
How much is this all tied to one particular implementation of the feature?

Honza
> 
> Qing
> 
> 
> > Honza
> >> 
> >> 
> >>> For example comdat that was cloned by IPA-SRA. See can_be_local_p and
> >>> comdat_can_be_unshared_p predicates.  Similar problem happens to clones created
> >>> by ipa-cp.
> >>> 
> >>> I guess we want to disable localization and cloning in this case as well.
> >>> I wonder what else.
> >> 
> >> Yes, I think we should make -finline-only-static incompatible with cloning and tree-sra too.
> >> 
> >> Qing
> >>> 
> >>> Honza
> 

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

[Martin Jambor]

Hi,

(this message is a part of the thread originating with
https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01018.html)

On Thu, Sep 27 2018, Jan Hubicka wrote:
>> > 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 other optimization will give up on these.
>> 
>> do you suggest that to set the global function as AVAIL_INTERPOSABLE when -finline-only-static 
>> is present? then we should avoid all issues?
>
> It seems to be reasonable direction I think, because it is what really happens
> (well AVAIL_INTERPOSABLE still does not assume that the interposition will
> happen at runtime, but it is an approximation and we may introduce something like
> AVAIL_RUNTIME_INTERPOSABLE if there is need for better difference).
> I wonder if -finline-only-static is good name for the flag though, because it
> does a lot more than that.  Maybe something like -flive-patching?
> How much is this all tied to one particular implementation of the feature?

We have just had a quick discussion with two upstream maintainers of
Linux kernel live-patching about this and the key points were:

1. SUSE live-patch creators (and I assume all that use the upstream
   live-patching method) use Martin Liska's (somewhat under-documented)
   -fdump-ipa-clones option and a utility he wrote
   (https://github.com/marxin/kgraft-analysis-tool) to deal with all
   kinds of inlining, IPA-CP and generally all IPA optimizations that
   internally create a clone.  The tool tells them what happened and
   also lists all callers that need to be live-patched.

2. However, there is growing concern about other IPA analyses that do
   not create a clone but still affect code generation in other
   functions.  Kernel developers have identified and disabled IPA-RA but
   there is more of them such as IPA-modref analysis, stack alignment
   propagation and possibly quite a few others which extract information
   from one function and use it a caller or perhaps even some
   almost-unrelated functions (such as detection of read-only and
   write-only static global variables).

   The kernel live-patching community would welcome if GCC had an option
   that could disable all such optimizations/analyses for which it
   cannot provide a list of all affected functions (i.e. which ones need
   to be live-patched if a particular function is).

   I assume this is orthogonal to the proposed -finline-only-static
   option, but the above approach seems superior in all respects.

3. The community would also like to be involved in these discussions,
   and therefore I am adding live-patching@vger.kernel.org to CC.  On a
   related note, they will also have a live-patching mini-summit at the
   Linux Plumbers conference in Vancouver in November where they plan to
   discuss what they would like GCC to provide.

Thanks,

Martin

...
>> >> 
>> >>> For example comdat that was cloned by IPA-SRA. See can_be_local_p and
>> >>> comdat_can_be_unshared_p predicates.  Similar problem happens to clones created
>> >>> by ipa-cp.
>> >>> 
>> >>> I guess we want to disable localization and cloning in this case as well.
>> >>> I wonder what else.
>> >> 
>> >> Yes, I think we should make -finline-only-static incompatible with cloning and tree-sra too.
>> >> 
>> >> Qing
>> >>> 
>> >>> Honza
>> 

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

[Qing Zhao]

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 <mjambor@suse.cz> wrote:
> 
> Hi,
> 
> (this message is a part of the thread originating with
> https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01018.html)
> 
> On Thu, Sep 27 2018, Jan Hubicka wrote:
>>>> 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 other optimization will give up on these.
>>> 
>>> do you suggest that to set the global function as AVAIL_INTERPOSABLE when -finline-only-static 
>>> is present? then we should avoid all issues?
>> 
>> It seems to be reasonable direction I think, because it is what really happens
>> (well AVAIL_INTERPOSABLE still does not assume that the interposition will
>> happen at runtime, but it is an approximation and we may introduce something like
>> AVAIL_RUNTIME_INTERPOSABLE if there is need for better difference).
>> I wonder if -finline-only-static is good name for the flag though, because it
>> does a lot more than that.  Maybe something like -flive-patching?
>> How much is this all tied to one particular implementation of the feature?
> 
> We have just had a quick discussion with two upstream maintainers of
> Linux kernel live-patching about this and the key points were:
> 
> 1. SUSE live-patch creators (and I assume all that use the upstream
>   live-patching method) use Martin Liska's (somewhat under-documented)
>   -fdump-ipa-clones option and a utility he wrote
>   (https://github.com/marxin/kgraft-analysis-tool) to deal with all
>   kinds of inlining, IPA-CP and generally all IPA optimizations that
>   internally create a clone.  The tool tells them what happened and
>   also lists all callers that need to be live-patched.
> 
> 2. However, there is growing concern about other IPA analyses that do
>   not create a clone but still affect code generation in other
>   functions.  Kernel developers have identified and disabled IPA-RA but
>   there is more of them such as IPA-modref analysis, stack alignment
>   propagation and possibly quite a few others which extract information
>   from one function and use it a caller or perhaps even some
>   almost-unrelated functions (such as detection of read-only and
>   write-only static global variables).
> 
>   The kernel live-patching community would welcome if GCC had an option
>   that could disable all such optimizations/analyses for which it
>   cannot provide a list of all affected functions (i.e. which ones need
>   to be live-patched if a particular function is).
> 
>   I assume this is orthogonal to the proposed -finline-only-static
>   option, but the above approach seems superior in all respects.
> 
> 3. The community would also like to be involved in these discussions,
>   and therefore I am adding live-patching@vger.kernel.org to CC.  On a
>   related note, they will also have a live-patching mini-summit at the
>   Linux Plumbers conference in Vancouver in November where they plan to
>   discuss what they would like GCC to provide.
> 
> Thanks,
> 
> Martin
> 
> ...
>>>>> 
>>>>>> For example comdat that was cloned by IPA-SRA. See can_be_local_p and
>>>>>> comdat_can_be_unshared_p predicates.  Similar problem happens to clones created
>>>>>> by ipa-cp.
>>>>>> 
>>>>>> I guess we want to disable localization and cloning in this case as well.
>>>>>> I wonder what else.
>>>>> 
>>>>> Yes, I think we should make -finline-only-static incompatible with cloning and tree-sra too.
>>>>> 
>>>>> Qing
>>>>>> 
>>>>>> Honza
>>> 

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

[Qing Zhao]

Hi, Martin,

I have studied a little more on

https://github.com/marxin/kgraft-analysis-tool/blob/master/README.md <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 a function that will be patched.
In this list, it includes all callers of the patched function, and the cloned functions from the patched function due to ipa const-propogation or ipa sra. 

My question:

what’s the current action to handle the cloned functions from the patched function due to ipa const-proposation or ipa sra, etc?

since those cloned functions are NOT in the source code level, how to generate the patches for the cloned functions? how to guarantee that after 
the patched function is changed, the same ipa const-propogation or ipa sra will still happened? 

a little confused here.

thanks.

Qing
> On Sep 27, 2018, at 7:19 AM, Martin Jambor <mjambor@suse.cz> wrote:
> 
> Hi,
> 
> (this message is a part of the thread originating with
> https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01018.html)
> 
> On Thu, Sep 27 2018, Jan Hubicka wrote:
>>>> 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 other optimization will give up on these.
>>> 
>>> do you suggest that to set the global function as AVAIL_INTERPOSABLE when -finline-only-static 
>>> is present? then we should avoid all issues?
>> 
>> It seems to be reasonable direction I think, because it is what really happens
>> (well AVAIL_INTERPOSABLE still does not assume that the interposition will
>> happen at runtime, but it is an approximation and we may introduce something like
>> AVAIL_RUNTIME_INTERPOSABLE if there is need for better difference).
>> I wonder if -finline-only-static is good name for the flag though, because it
>> does a lot more than that.  Maybe something like -flive-patching?
>> How much is this all tied to one particular implementation of the feature?
> 
> We have just had a quick discussion with two upstream maintainers of
> Linux kernel live-patching about this and the key points were:
> 
> 1. SUSE live-patch creators (and I assume all that use the upstream
>   live-patching method) use Martin Liska's (somewhat under-documented)
>   -fdump-ipa-clones option and a utility he wrote
>   (https://github.com/marxin/kgraft-analysis-tool) to deal with all
>   kinds of inlining, IPA-CP and generally all IPA optimizations that
>   internally create a clone.  The tool tells them what happened and
>   also lists all callers that need to be live-patched.
> 
> 2. However, there is growing concern about other IPA analyses that do
>   not create a clone but still affect code generation in other
>   functions.  Kernel developers have identified and disabled IPA-RA but
>   there is more of them such as IPA-modref analysis, stack alignment
>   propagation and possibly quite a few others which extract information
>   from one function and use it a caller or perhaps even some
>   almost-unrelated functions (such as detection of read-only and
>   write-only static global variables).
> 
>   The kernel live-patching community would welcome if GCC had an option
>   that could disable all such optimizations/analyses for which it
>   cannot provide a list of all affected functions (i.e. which ones need
>   to be live-patched if a particular function is).
> 
>   I assume this is orthogonal to the proposed -finline-only-static
>   option, but the above approach seems superior in all respects.
> 
> 3. The community would also like to be involved in these discussions,
>   and therefore I am adding live-patching@vger.kernel.org to CC.  On a
>   related note, they will also have a live-patching mini-summit at the
>   Linux Plumbers conference in Vancouver in November where they plan to
>   discuss what they would like GCC to provide.
> 
> Thanks,
> 
> Martin
> 

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

[Martin Jambor]

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.com/marxin/kgraft-analysis-tool/blob/master/README.md <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 a function that will be patched.
> In this list, it includes all callers of the patched function, and the cloned functions from the patched function due to ipa const-propogation or ipa sra. 
>
> My question:
>
> what’s the current action to handle the cloned functions from the
> patched function due to ipa const-proposation or ipa sra, etc?

If we want to patch an inlined, cloned, or IPA-SRAed function, we also
patch all of its callers.

>
> since those cloned functions are NOT in the source code level, how to generate the patches for the cloned functions? how to guarantee that after 
> the patched function is changed, the same ipa const-propogation or ipa
> sra will still happened?

You don't.

Martin

>
> a little confused here.
>
> thanks.
>
> Qing
>> On Sep 27, 2018, at 7:19 AM, Martin Jambor <mjambor@suse.cz> wrote:
>> 
>> Hi,
>> 
>> (this message is a part of the thread originating with
>> https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01018.html)
>> 
>> On Thu, Sep 27 2018, Jan Hubicka wrote:
>>>>> 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 other optimization will give up on these.
>>>> 
>>>> do you suggest that to set the global function as AVAIL_INTERPOSABLE when -finline-only-static 
>>>> is present? then we should avoid all issues?
>>> 
>>> It seems to be reasonable direction I think, because it is what really happens
>>> (well AVAIL_INTERPOSABLE still does not assume that the interposition will
>>> happen at runtime, but it is an approximation and we may introduce something like
>>> AVAIL_RUNTIME_INTERPOSABLE if there is need for better difference).
>>> I wonder if -finline-only-static is good name for the flag though, because it
>>> does a lot more than that.  Maybe something like -flive-patching?
>>> How much is this all tied to one particular implementation of the feature?
>> 
>> We have just had a quick discussion with two upstream maintainers of
>> Linux kernel live-patching about this and the key points were:
>> 
>> 1. SUSE live-patch creators (and I assume all that use the upstream
>>   live-patching method) use Martin Liska's (somewhat under-documented)
>>   -fdump-ipa-clones option and a utility he wrote
>>   (https://github.com/marxin/kgraft-analysis-tool) to deal with all
>>   kinds of inlining, IPA-CP and generally all IPA optimizations that
>>   internally create a clone.  The tool tells them what happened and
>>   also lists all callers that need to be live-patched.
>> 
>> 2. However, there is growing concern about other IPA analyses that do
>>   not create a clone but still affect code generation in other
>>   functions.  Kernel developers have identified and disabled IPA-RA but
>>   there is more of them such as IPA-modref analysis, stack alignment
>>   propagation and possibly quite a few others which extract information
>>   from one function and use it a caller or perhaps even some
>>   almost-unrelated functions (such as detection of read-only and
>>   write-only static global variables).
>> 
>>   The kernel live-patching community would welcome if GCC had an option
>>   that could disable all such optimizations/analyses for which it
>>   cannot provide a list of all affected functions (i.e. which ones need
>>   to be live-patched if a particular function is).
>> 
>>   I assume this is orthogonal to the proposed -finline-only-static
>>   option, but the above approach seems superior in all respects.
>> 
>> 3. The community would also like to be involved in these discussions,
>>   and therefore I am adding live-patching@vger.kernel.org to CC.  On a
>>   related note, they will also have a live-patching mini-summit at the
>>   Linux Plumbers conference in Vancouver in November where they plan to
>>   discuss what they would like GCC to provide.
>> 
>> Thanks,
>> 
>> Martin
>> 

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

[Qing Zhao]

> On Oct 2, 2018, at 3:33 AM, Martin Jambor <mjambor@suse.cz> 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.com/marxin/kgraft-analysis-tool/blob/master/README.md <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 a function that will be patched.
>> In this list, it includes all callers of the patched function, and the cloned functions from the patched function due to ipa const-propogation or ipa sra. 
>> 
>> My question:
>> 
>> what’s the current action to handle the cloned functions from the
>> patched function due to ipa const-proposation or ipa sra, etc?
> 
> If we want to patch an inlined, cloned, or IPA-SRAed function, we also
> patch all of its callers.

take the example from the link:

$ gcc /home/marxin/Programming/linux/aesni-intel_glue.i -O2 -fdump-ipa-clones -c
$ ./kgraft-ipa-analysis.py aesni-intel_glue.i.000i.ipa-clones

[..skipped..]
Function: fls64/63 (./arch/x86/include/asm/bitops.h:479:90)
  inlining to: __ilog2_u64/132 (include/linux/log2.h:40:5)
    inlining to: ablkcipher_request_alloc/1639 (include/linux/crypto.h:979:82)
      constprop: ablkcipher_request_alloc.constprop.8/3198 (include/linux/crypto.h:979:82)
    inlining to: helper_rfc4106_decrypt/3007 (arch/x86/crypto/aesni-intel_glue.c:1016:12)
    inlining to: helper_rfc4106_encrypt/3006 (arch/x86/crypto/aesni-intel_glue.c:939:12)

  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)
    helper_rfc4106_decrypt/3007 (arch/x86/crypto/aesni-intel_glue.c:1016:12)
    helper_rfc4106_encrypt/3006 (arch/x86/crypto/aesni-intel_glue.c:939:12)
[..skipped..]


if we want to patch the function “fls64/63”,  what else functions we need to patch, too? my guess is:

**all the callers:
__ilog2_u64/132
ablkcipher_request_alloc/1639
helper_rfc4106_decrypt/3007
helper_rfc4106_encrypt/3006 
**and:
ablkcipher_request_alloc.constprop.8/3198
is the above correct?

how to generate patch for ablkcipher_request_alloc.constprop.8/3198? since it’s not a function in the source code?

Qing

> 
>> 
>> since those cloned functions are NOT in the source code level, how to generate the patches for the cloned functions? how to guarantee that after 
>> the patched function is changed, the same ipa const-propogation or ipa
>> sra will still happened?
> 
> You don't.
> 
> Martin
> 
>> 

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

[Martin Liška]

On 10/2/18 3:28 PM, Qing Zhao wrote:
> 
>> On Oct 2, 2018, at 3:33 AM, Martin Jambor <mjambor@suse.cz> 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.com/marxin/kgraft-analysis-tool/blob/master/README.md <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 a function that will be patched.
>>> In this list, it includes all callers of the patched function, and the cloned functions from the patched function due to ipa const-propogation or ipa sra. 
>>>
>>> My question:
>>>
>>> what’s the current action to handle the cloned functions from the
>>> patched function due to ipa const-proposation or ipa sra, etc?
>>
>> If we want to patch an inlined, cloned, or IPA-SRAed function, we also
>> patch all of its callers.
> 
> take the example from the link:
> 
> $ gcc /home/marxin/Programming/linux/aesni-intel_glue.i -O2 -fdump-ipa-clones -c
> $ ./kgraft-ipa-analysis.py aesni-intel_glue.i.000i.ipa-clones
> 
> [..skipped..]
> Function: fls64/63 (./arch/x86/include/asm/bitops.h:479:90)
>   inlining to: __ilog2_u64/132 (include/linux/log2.h:40:5)
>     inlining to: ablkcipher_request_alloc/1639 (include/linux/crypto.h:979:82)
>       constprop: ablkcipher_request_alloc.constprop.8/3198 (include/linux/crypto.h:979:82)
>     inlining to: helper_rfc4106_decrypt/3007 (arch/x86/crypto/aesni-intel_glue.c:1016:12)
>     inlining to: helper_rfc4106_encrypt/3006 (arch/x86/crypto/aesni-intel_glue.c:939:12)
> 
>   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)
>     helper_rfc4106_decrypt/3007 (arch/x86/crypto/aesni-intel_glue.c:1016:12)
>     helper_rfc4106_encrypt/3006 (arch/x86/crypto/aesni-intel_glue.c:939:12)
> [..skipped..]
> 
> 
> if we want to patch the function “fls64/63”,  what else functions we need to patch, too? my guess is:

Hi.

Yes, 'Affected functions' is exactly the list of functions you want to patch.

> 
> **all the callers:
> __ilog2_u64/132
> ablkcipher_request_alloc/1639
> helper_rfc4106_decrypt/3007
> helper_rfc4106_encrypt/3006 
> **and:
> ablkcipher_request_alloc.constprop.8/3198
> is the above correct?
> 
> how to generate patch for ablkcipher_request_alloc.constprop.8/3198? since it’s not a function in the source code?

Well, it's a 'static inline' function in a header file thus the function will be inlined in all usages.
In this particular case there's no such caller function, so you're fine.

Martin

> 
> Qing
> 
>>
>>>
>>> since those cloned functions are NOT in the source code level, how to generate the patches for the cloned functions? how to guarantee that after 
>>> the patched function is changed, the same ipa const-propogation or ipa
>>> sra will still happened?
>>
>> You don't.
>>
>> Martin
>>
>>>
> 

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

[Qing Zhao]

> On Oct 2, 2018, at 9:02 AM, Martin Liška <mliska@suse.cz> wrote:
> 
> On 10/2/18 3:28 PM, Qing Zhao wrote:
>> 
>>> On Oct 2, 2018, at 3:33 AM, Martin Jambor <mjambor@suse.cz> 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.com/marxin/kgraft-analysis-tool/blob/master/README.md <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 a function that will be patched.
>>>> In this list, it includes all callers of the patched function, and the cloned functions from the patched function due to ipa const-propogation or ipa sra. 
>>>> 
>>>> My question:
>>>> 
>>>> what’s the current action to handle the cloned functions from the
>>>> patched function due to ipa const-proposation or ipa sra, etc?
>>> 
>>> If we want to patch an inlined, cloned, or IPA-SRAed function, we also
>>> patch all of its callers.
>> 
>> take the example from the link:
>> 
>> $ gcc /home/marxin/Programming/linux/aesni-intel_glue.i -O2 -fdump-ipa-clones -c
>> $ ./kgraft-ipa-analysis.py aesni-intel_glue.i.000i.ipa-clones
>> 
>> [..skipped..]
>> Function: fls64/63 (./arch/x86/include/asm/bitops.h:479:90)
>>  inlining to: __ilog2_u64/132 (include/linux/log2.h:40:5)
>>    inlining to: ablkcipher_request_alloc/1639 (include/linux/crypto.h:979:82)
>>      constprop: ablkcipher_request_alloc.constprop.8/3198 (include/linux/crypto.h:979:82)
>>    inlining to: helper_rfc4106_decrypt/3007 (arch/x86/crypto/aesni-intel_glue.c:1016:12)
>>    inlining to: helper_rfc4106_encrypt/3006 (arch/x86/crypto/aesni-intel_glue.c:939:12)
>> 
>>  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)
>>    helper_rfc4106_decrypt/3007 (arch/x86/crypto/aesni-intel_glue.c:1016:12)
>>    helper_rfc4106_encrypt/3006 (arch/x86/crypto/aesni-intel_glue.c:939:12)
>> [..skipped..]
>> 
>> 
>> if we want to patch the function “fls64/63”,  what else functions we need to patch, too? my guess is:
> 
> Hi.
> 
> Yes, 'Affected functions' is exactly the list of functions you want to patch.
> 
>> 
>> **all the callers:
>> __ilog2_u64/132
>> ablkcipher_request_alloc/1639
>> helper_rfc4106_decrypt/3007
>> helper_rfc4106_encrypt/3006 
>> **and:
>> ablkcipher_request_alloc.constprop.8/3198
>> is the above correct?
>> 
>> how to generate patch for ablkcipher_request_alloc.constprop.8/3198? since it’s not a function in the source code?
> 
> Well, it's a 'static inline' function in a header file thus the function will be inlined in all usages.
> In this particular case there's no such caller function, so you're fine.

So, for cloned functions, you have to analyze them case by case manually to see their callers?
why not just disable ipa-cp or ipa-sra completely?

Qing
> 

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

[Martin Liška]

On 10/2/18 4:46 PM, Qing Zhao wrote:
> 
>> On Oct 2, 2018, at 9:02 AM, Martin Liška <mliska@suse.cz> wrote:
>>
>> On 10/2/18 3:28 PM, Qing Zhao wrote:
>>>
>>>> On Oct 2, 2018, at 3:33 AM, Martin Jambor <mjambor@suse.cz> 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.com/marxin/kgraft-analysis-tool/blob/master/README.md <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 a function that will be patched.
>>>>> In this list, it includes all callers of the patched function, and the cloned functions from the patched function due to ipa const-propogation or ipa sra. 
>>>>>
>>>>> My question:
>>>>>
>>>>> what’s the current action to handle the cloned functions from the
>>>>> patched function due to ipa const-proposation or ipa sra, etc?
>>>>
>>>> If we want to patch an inlined, cloned, or IPA-SRAed function, we also
>>>> patch all of its callers.
>>>
>>> take the example from the link:
>>>
>>> $ gcc /home/marxin/Programming/linux/aesni-intel_glue.i -O2 -fdump-ipa-clones -c
>>> $ ./kgraft-ipa-analysis.py aesni-intel_glue.i.000i.ipa-clones
>>>
>>> [..skipped..]
>>> Function: fls64/63 (./arch/x86/include/asm/bitops.h:479:90)
>>>  inlining to: __ilog2_u64/132 (include/linux/log2.h:40:5)
>>>    inlining to: ablkcipher_request_alloc/1639 (include/linux/crypto.h:979:82)
>>>      constprop: ablkcipher_request_alloc.constprop.8/3198 (include/linux/crypto.h:979:82)
>>>    inlining to: helper_rfc4106_decrypt/3007 (arch/x86/crypto/aesni-intel_glue.c:1016:12)
>>>    inlining to: helper_rfc4106_encrypt/3006 (arch/x86/crypto/aesni-intel_glue.c:939:12)
>>>
>>>  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)
>>>    helper_rfc4106_decrypt/3007 (arch/x86/crypto/aesni-intel_glue.c:1016:12)
>>>    helper_rfc4106_encrypt/3006 (arch/x86/crypto/aesni-intel_glue.c:939:12)
>>> [..skipped..]
>>>
>>>
>>> if we want to patch the function “fls64/63”,  what else functions we need to patch, too? my guess is:
>>
>> Hi.
>>
>> Yes, 'Affected functions' is exactly the list of functions you want to patch.
>>
>>>
>>> **all the callers:
>>> __ilog2_u64/132
>>> ablkcipher_request_alloc/1639
>>> helper_rfc4106_decrypt/3007
>>> helper_rfc4106_encrypt/3006 
>>> **and:
>>> ablkcipher_request_alloc.constprop.8/3198
>>> is the above correct?
>>>
>>> how to generate patch for ablkcipher_request_alloc.constprop.8/3198? since it’s not a function in the source code?
>>
>> Well, it's a 'static inline' function in a header file thus the function will be inlined in all usages.
>> In this particular case there's no such caller function, so you're fine.
> 
> So, for cloned functions, you have to analyze them case by case manually to see their callers?

No, the tool should provide complete list of affected functions.

> why not just disable ipa-cp or ipa-sra completely?

Because the optimizations create function clones, which are trackable with my tool
and one knows then all affected functions.

You can disable the optimizations, but you'll miss some performance benefit provide
by compiler.

Note that as Martin Jambor mentioned in point 2) there are also IPA optimizations that
do not create clones. These should be listed and eventually disabled for kernel live
patching.

Martin

> 
> Qing
>>
> 

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

[Qing Zhao]

> On Oct 2, 2018, at 9:55 AM, Martin Liška <mliska@suse.cz> 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)
>>>>   helper_rfc4106_decrypt/3007 (arch/x86/crypto/aesni-intel_glue.c:1016:12)
>>>>   helper_rfc4106_encrypt/3006 (arch/x86/crypto/aesni-intel_glue.c:939:12)
>>>> [..skipped..]
>>>> 
>>>> 
>>>> if we want to patch the function “fls64/63”,  what else functions we need to patch, too? my guess is:
>>> 
>>> Hi.
>>> 
>>> Yes, 'Affected functions' is exactly the list of functions you want to patch.
>>> 
>>>> 
>>>> **all the callers:
>>>> __ilog2_u64/132
>>>> ablkcipher_request_alloc/1639
>>>> helper_rfc4106_decrypt/3007
>>>> helper_rfc4106_encrypt/3006 
>>>> **and:
>>>> ablkcipher_request_alloc.constprop.8/3198
>>>> is the above correct?
>>>> 
>>>> how to generate patch for ablkcipher_request_alloc.constprop.8/3198? since it’s not a function in the source code?
>>> 
>>> Well, it's a 'static inline' function in a header file thus the function will be inlined in all usages.
>>> In this particular case there's no such caller function, so you're fine.
>> 
>> So, for cloned functions, you have to analyze them case by case manually to see their callers?
> 
> No, the tool should provide complete list of affected functions.

So,  the tool will provide the callers of the cloned routine? then we will patch the callers of the cloned routine, Not the cloned routine itself?

> 
>> why not just disable ipa-cp or ipa-sra completely?
> 
> Because the optimizations create function clones, which are trackable with my tool
> and one knows then all affected functions.
Okay. I see. 
> 
> You can disable the optimizations, but you'll miss some performance benefit provide
> by compiler.
> 
> Note that as Martin Jambor mentioned in point 2) there are also IPA optimizations that
> do not create clones. These should be listed and eventually disabled for kernel live
> patching.

Yes, such IPA analyzes should be disabled.  we need to identify a complete list of such analyzes.

thanks.

Qing

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

[Martin Liška]

On 10/2/18 5:12 PM, Qing Zhao wrote:
> 
>> On Oct 2, 2018, at 9:55 AM, Martin Liška <mliska@suse.cz <mailto:mliska@suse.cz>> 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)
>>>>>   helper_rfc4106_decrypt/3007 (arch/x86/crypto/aesni-intel_glue.c:1016:12)
>>>>>   helper_rfc4106_encrypt/3006 (arch/x86/crypto/aesni-intel_glue.c:939:12)
>>>>> [..skipped..]
>>>>>
>>>>>
>>>>> if we want to patch the function “fls64/63”,  what else functions we need to patch, too? my guess is:
>>>>
>>>> Hi.
>>>>
>>>> Yes, 'Affected functions' is exactly the list of functions you want to patch.
>>>>
>>>>>
>>>>> **all the callers:
>>>>> __ilog2_u64/132
>>>>> ablkcipher_request_alloc/1639
>>>>> helper_rfc4106_decrypt/3007
>>>>> helper_rfc4106_encrypt/3006
>>>>> **and:
>>>>> ablkcipher_request_alloc.constprop.8/3198
>>>>> is the above correct?
>>>>>
>>>>> how to generate patch for ablkcipher_request_alloc.constprop.8/3198? since it’s not a function in the source code?
>>>>
>>>> Well, it's a 'static inline' function in a header file thus the function will be inlined in all usages.
>>>> In this particular case there's no such caller function, so you're fine.
>>>
>>> So, for cloned functions, you have to analyze them case by case manually to see their callers?
>>
>> No, the tool should provide complete list of affected functions.
> 
> So,  the tool will provide the callers of the cloned routine?

No, the tool does not list callers of affected functions. But function call ABI is reasonable
live-patching boundary.

then we will patch the callers of the cloned routine, Not the cloned routine itself?
> 
>>
>>> why not just disable ipa-cp or ipa-sra completely?
>>
>> Because the optimizations create function clones, which are trackable with my tool
>> and one knows then all affected functions.
> Okay. I see.
>>
>> You can disable the optimizations, but you'll miss some performance benefit provide
>> by compiler.
>>
>> Note that as Martin Jambor mentioned in point 2) there are also IPA optimizations that
>> do not create clones. These should be listed and eventually disabled for kernel live
>> patching.
> 
> Yes, such IPA analyzes should be disabled.  we need to identify a complete list of such analyzes.

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.

Martin

> 
> thanks.
> 
> Qing
> 

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

[Richard Biener]

On October 2, 2018 7:13:13 PM GMT+02:00, "Martin Liška" <mliska@suse.cz> wrote:
>On 10/2/18 5:12 PM, Qing Zhao wrote:
>> 
>>> On Oct 2, 2018, at 9:55 AM, Martin Liška <mliska@suse.cz
><mailto:mliska@suse.cz>> 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)
>>>>>>   helper_rfc4106_decrypt/3007
>(arch/x86/crypto/aesni-intel_glue.c:1016:12)
>>>>>>   helper_rfc4106_encrypt/3006
>(arch/x86/crypto/aesni-intel_glue.c:939:12)
>>>>>> [..skipped..]
>>>>>>
>>>>>>
>>>>>> if we want to patch the function “fls64/63”,  what else functions
>we need to patch, too? my guess is:
>>>>>
>>>>> Hi.
>>>>>
>>>>> Yes, 'Affected functions' is exactly the list of functions you
>want to patch.
>>>>>
>>>>>>
>>>>>> **all the callers:
>>>>>> __ilog2_u64/132
>>>>>> ablkcipher_request_alloc/1639
>>>>>> helper_rfc4106_decrypt/3007
>>>>>> helper_rfc4106_encrypt/3006
>>>>>> **and:
>>>>>> ablkcipher_request_alloc.constprop.8/3198
>>>>>> is the above correct?
>>>>>>
>>>>>> how to generate patch for
>ablkcipher_request_alloc.constprop.8/3198? since it’s not a function in
>the source code?
>>>>>
>>>>> Well, it's a 'static inline' function in a header file thus the
>function will be inlined in all usages.
>>>>> In this particular case there's no such caller function, so you're
>fine.
>>>>
>>>> So, for cloned functions, you have to analyze them case by case
>manually to see their callers?
>>>
>>> No, the tool should provide complete list of affected functions.
>> 
>> So,  the tool will provide the callers of the cloned routine?
>
>No, the tool does not list callers of affected functions. But function
>call ABI is reasonable
>live-patching boundary.
>
>then we will patch the callers of the cloned routine, Not the cloned
>routine itself?
>> 
>>>
>>>> why not just disable ipa-cp or ipa-sra completely?
>>>
>>> Because the optimizations create function clones, which are
>trackable with my tool
>>> and one knows then all affected functions.
>> Okay. I see.
>>>
>>> You can disable the optimizations, but you'll miss some performance
>benefit provide
>>> by compiler.
>>>
>>> Note that as Martin Jambor mentioned in point 2) there are also IPA
>optimizations that
>>> do not create clones. These should be listed and eventually disabled
>for kernel live
>>> patching.
>> 
>> Yes, such IPA analyzes should be disabled.  we need to identify a
>complete list of such analyzes.
>
>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.

One could also compute the list of possibly affected functions from such semantic changes. 

Richard. 

>Martin
>
>> 
>> thanks.
>> 
>> Qing
>> 

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

[Qing Zhao]

> On Oct 2, 2018, at 1:09 PM, Richard Biener <richard.guenther@gmail.com> wrote:
> 
>>>> 
>>> 
>>> Yes, such IPA analyzes should be disabled.  we need to identify a
>> complete list of such analyzes.
>> 
>> 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.
> 
> One could also compute the list of possibly affected functions from such semantic changes. 

theoretically, Yes.   

So, here comes the next question:

what will be the better approach for helping live-patching?

A. disable all the optimization/analyzes that changing a function based on other functions.  this includes most of 
the IPA optimizations, inlining, cloning, ipa side effect analysis, etc.

B. enable all such optimizations, but compute the list of possibly affected functions from those IPA optimizations.

C. enable part of them and disable the other part of them.  for the part of enabled ones,  compute the list of possibly affected functions
from them.

Or, we might need an option to provide the support for all the above?

-fease-live-patching={NONE|ALL|C1|C2|…|Cn}

NONE: disable all IPA optimizations;
ALL: enable all IPA optimizations, compute the list of affected functions;
C1: 
C2:
…
Cn: 

C1 to Cn will be part of the optimizations, for exmaple, C1 might be only-static-inline, C2 might be inline-clone,  etc. 

any comments or suggestions?

Qing


> 
> Richard. 
> 
>> Martin

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

[Martin Liška]

On 10/2/18 8:58 PM, Qing Zhao wrote:
> 
>> On Oct 2, 2018, at 1:09 PM, Richard Biener <richard.guenther@gmail.com> wrote:
>>
>>>>>
>>>>
>>>> Yes, such IPA analyzes should be disabled.  we need to identify a
>>> complete list of such analyzes.
>>>
>>> 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.
>>
>> One could also compute the list of possibly affected functions from such semantic changes. 
> 
> theoretically, Yes.   
> 
> So, here comes the next question:
> 
> what will be the better approach for helping live-patching?
> 
> A. disable all the optimization/analyzes that changing a function based on other functions.  this includes most of 
> the IPA optimizations, inlining, cloning, ipa side effect analysis, etc.
> 
> B. enable all such optimizations, but compute the list of possibly affected functions from those IPA optimizations.
> 
> C. enable part of them and disable the other part of them.  for the part of enabled ones,  compute the list of possibly affected functions
> from them.
> 
> Or, we might need an option to provide the support for all the above?

That's basically equal to disabling the optimizations via -fno-ipa-ra -fno-ipa-*.

> 
> -fease-live-patching={NONE|ALL|C1|C2|…|Cn}
> 
> NONE: disable all IPA optimizations;
> ALL: enable all IPA optimizations, compute the list of affected functions;
> C1: 
> C2:
> …
> Cn: 
> 
> C1 to Cn will be part of the optimizations, for exmaple, C1 might be only-static-inline, C2 might be inline-clone,  etc. 

As said, I would like to see listed all possibly problematic optimizations with their corresponding flags.
Having that we can think about an -flive-patching option that will disable bunch of these flags.
Note that we are not sure we already have flags for all IPA optimizations that can possibly
influence live-patching. We've been working on the listing.

Martin

> 
> any comments or suggestions?
> 
> Qing
> 
> 
>>
>> Richard. 
>>
>>> Martin
> 

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

[Martin Jambor]

Hi,

On Tue, Oct 02 2018, Qing Zhao wrote:
> So, here comes the next question:
>
> what will be the better approach for helping live-patching?
>
> A. disable all the optimization/analyzes that changing a function based on other functions.  this includes most of 
> the IPA optimizations, inlining, cloning, ipa side effect analysis, etc.

We came to the conclusion that we do not want to disable (any) inlining
- primarily for performance reasons but also because of always_inline.
When you have to deal with inlining, you can use the same mechanism for
IPA-CP clones, IPA-SRA and anything that creates clones and callers need
to be patched.

Always_inline is also the reason why I would discourage anyone from
attempting this, it looks too much like an irresolvable conflict.

>
> B. enable all such optimizations, but compute the list of possibly affected functions from those IPA optimizations.

Although certainly possible, we came to the conclusion that it would be
impractical to attempt to track all decisions affected by, say, a
function being pure, or a variable read-only, etc.  Impractical to the
point when at least I personally would also discourage anyone from
attempting this too, it would be necessary to record this info deep
inside AA, VRP, who know what else, and keep it up to date.

>
> C. enable part of them and disable the other part of them.  for the part of enabled ones,  compute the list of possibly affected functions
> from them.

Which means we would like to go this route.

Martin

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

[Qing Zhao]

> On Oct 3, 2018, at 5:19 AM, Martin Jambor <mjambor@suse.cz> wrote:
> 
> Hi,
> 
> On Tue, Oct 02 2018, Qing Zhao wrote:
>> So, here comes the next question:
>> 
>> what will be the better approach for helping live-patching?
>> 
>> A. disable all the optimization/analyzes that changing a function based on other functions.  this includes most of 
>> the IPA optimizations, inlining, cloning, ipa side effect analysis, etc.
> 
> We came to the conclusion that we do not want to disable (any) inlining
> - primarily for performance reasons but also because of always_inline.
> When you have to deal with inlining, you can use the same mechanism for
> IPA-CP clones, IPA-SRA and anything that creates clones and callers need
> to be patched.
> 
> Always_inline is also the reason why I would discourage anyone from
> attempting this, it looks too much like an irresolvable conflict.

Okay.

However, there are also other users of live-patching who request only inlining static routines to control the code size explosion and debugging
complexity as the start of the whole discussion. 

in addition to control inlining, I am not sure whether we want to control  ipa-cp, ipa-sra, etc to further control the code size and debugging complexity?

we should also include such request into this work.

> 
>> 
>> B. enable all such optimizations, but compute the list of possibly affected functions from those IPA optimizations.
> 
> Although certainly possible, we came to the conclusion that it would be
> impractical to attempt to track all decisions affected by, say, a
> function being pure, or a variable read-only, etc.  Impractical to the
> point when at least I personally would also discourage anyone from
> attempting this too, it would be necessary to record this info deep
> inside AA, VRP, who know what else, and keep it up to date.

I think that theoretically the compiler should be able to do this.  But the impacted routine list might be huge. that also lead problems of code size explosion and debugging complexity.

> 
>> 
>> C. enable part of them and disable the other part of them.  for the part of enabled ones,  compute the list of possibly affected functions
>> from them.
> 
> Which means we would like to go this route.
Qing
> 
> Martin
> 

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

[Richard Biener]

On Wed, Oct 3, 2018 at 6:00 PM Qing Zhao <qing.zhao@oracle.com> wrote:
>
>
> > On Oct 3, 2018, at 5:19 AM, Martin Jambor <mjambor@suse.cz> wrote:
> >
> > Hi,
> >
> > On Tue, Oct 02 2018, Qing Zhao wrote:
> >> So, here comes the next question:
> >>
> >> what will be the better approach for helping live-patching?
> >>
> >> A. disable all the optimization/analyzes that changing a function based on other functions.  this includes most of
> >> the IPA optimizations, inlining, cloning, ipa side effect analysis, etc.
> >
> > We came to the conclusion that we do not want to disable (any) inlining
> > - primarily for performance reasons but also because of always_inline.
> > When you have to deal with inlining, you can use the same mechanism for
> > IPA-CP clones, IPA-SRA and anything that creates clones and callers need
> > to be patched.
> >
> > Always_inline is also the reason why I would discourage anyone from
> > attempting this, it looks too much like an irresolvable conflict.
>
> Okay.
>
> However, there are also other users of live-patching who request only inlining static routines to control the code size explosion and debugging
> complexity as the start of the whole discussion.
>
> in addition to control inlining, I am not sure whether we want to control  ipa-cp, ipa-sra, etc to further control the code size and debugging complexity?
>
> we should also include such request into this work.
>
> >
> >>
> >> B. enable all such optimizations, but compute the list of possibly affected functions from those IPA optimizations.
> >
> > Although certainly possible, we came to the conclusion that it would be
> > impractical to attempt to track all decisions affected by, say, a
> > function being pure, or a variable read-only, etc.  Impractical to the
> > point when at least I personally would also discourage anyone from
> > attempting this too, it would be necessary to record this info deep
> > inside AA, VRP, who know what else, and keep it up to date.
>
> I think that theoretically the compiler should be able to do this.  But the impacted routine list might be huge. that also lead problems of code size explosion and debugging complexity.

I think it boils down to have a "global" lattice of non-VARYING-X
"because of $FN" for each of the analyses X properly
propagated along the callgraph.

Something as "simple" as annotating each function output or inlined
with its lattice state "PURE, 1st param ~[0,0]", etc.
could be helpful to spot differences before/after the patch and raise a flag.

Richard.

> >
> >>
> >> C. enable part of them and disable the other part of them.  for the part of enabled ones,  compute the list of possibly affected functions
> >> from them.
> >
> > Which means we would like to go this route.
> Qing
> >
> > Martin
> >
>

[RFC] GCC support for live-patching

[Qing Zhao]

Hi,

After more detailed study of GCC’s IPA optimizations, further study of the current available kernel live patching schemes and 
other live-patching user’s request, I came up with the following initial proposal in GCC to mainly support live-patching users who
manually create patches. 

Please take a look at the writeup, and let me know your opinions and suggestions.

thanks a lot.

Qing

===========

options to help live patching in GCC

Qing Zhao

10/17/2018
================================================

0. The proposal:

Provide two first class options in GCC to help live-patching users
who manually generate patches. 

A. an option to control GCC's IPA optimizations to provide a safe 
compilation for live-patching purpose. At the same time, provides
multiple-level control of patch code-size and run time performance 
tradeoff. 

-fease-live-patching={none|only-inline-static|inline|inline-clone}

When -fease-live-patching specified without any value, the default value
is "inline-clone". 

B. an option to compute the impacted function lists and dump them for
live-patching users.  

-flive-patching-list={func_name|all}{,dump_func_name}

This option guides the compiler to compute the list of impacted routines for
live patching. It only has effect when it is combined with -fease-live-patching.

when -flive-patching-list is specified without any value, the default value is
"all", i.e, compute the lists of impacted routines for all routines and dump 
them into stdout.

Please see more details of these two options in section 3. Details of the proposal.


1. A study of Kernel live patching schemes.

Three major kernel live patching tools:  https://lwn.net/Articles/734765/

* ksplice:   http://www.ksplice.com/doc/ksplice.pdf
* kpatch:    https://lwn.net/Articles/597123/
            https://github.com/dynup/kpatch
* kGraft:    
https://pdfs.semanticscholar.org/presentation/af4c/895aa3fef0cc2b501317aaec9d91ba2d704c.pdf

In the above, ksplice and kpatch can automatically generate binary patches 
as following:

   * a collection of tools which convert a source diff patch to a patch
module. They work by compiling the kernel both with and without the source
patch, comparing the binaries, and generating a binary patch module which 
includes new binary versions of the functions to be replaced.

on the other hand, kGraft offers a way to create patches entirely by hand. 
The source of the patch is a single C file, easy to review, easy to
maintain. 

In addition to kGraft, there are other live patching tools that prefer
creating patches by hand for the similar reason. 

The compiler support is mainly for the above live patching tools that create 
patches entirely by hand. the major purpose is:

 * control patch code size and debug complexity;
 * keep good run time performance;

2. the major problems of compiler in live patching:

For the live patching schemes that create patches by hand, when patching 
one function, there might a list of functions that will be impacted by 
this patched function due to compiler optimization/analyses (mainly IPA
optimization/analyses), a complete patch will include the patched function
and all impacted functions. Usually, there are two major factors to be
considered in such live patching schemes:

 * patch code size, one major factor is the length of the list 
of impacted functions;
 * run time performance.

If we want to control the patch code size, to make the list of impacted 
functions minimum, we have to disable corresponding compiler optimizations 
as much as possible.

On the other hand, in order to keep good run time performance, we need to 
keep the compiler optimization as much as possible. 

So, there should be some tradeoff between these two factors. 

The following are two major categories of compiler optimizations 
we should considered:

 A. compiler optimizations/analyses that extract ipa info from
a routine's body, and use such info to guide other optimization.

Since the body of the routine might be changed for live patching, 
the ipa info extracted from the body of the routine also changes,
as a result, all the routines that directly or indirectly utilize 
the ipa info from this routine are in the list of the impacted 
routines.  

Most of the IPA analyses and optimization belong to this category. 

Although theoretically the impacted routine list from such ipa 
phases could be computed, the list might be huge. Such huge list
of impacted routine might explode the patch code size too much. 

Therefore, it might be more pratical to just completely disable such
ipa optimizations/analyses.

 B. Inlining, and all optimizaitons that internally create clone. 
for example, cloning, ipa-sra, partial inlining, etc.
We can track the effect and impacted routine of such optimization 
easily. 
Such kind of optimization could be kept, but the compiler
should provide the list of impacted functions if a routine need to 
be patched.

There is patch code size explosion potential even with only enabling
inlining and cloning for live patching. Users need a way to control 
the inlining and cloning in order to control the code size explosion 
and complexity of debugging.

3. Details of the proposal:

What should GCC provide to live-patching users who manually create
patches? 

A. an option to control GCC's IPA optimizations to provide a safe 
compilation for live-patching purpose. At the same time, provides
multiple levels of patch code-size and run time performance tradeoff. 

-fease-live-patching={none|only-inline-static|inline|inline-clone}

-fease-live-patching=none

  Disable all ipa optimizations/analyses in GCC.  As a result, any
routine can be patched independently without impacting other routines.

-fease-live-patching=only-inline-static

  Only enable inlining of static functions, disable all other IPA 
optimizations/analyses. As a result, when patching a static routine,
all its callers need to be patches as well.

-fease-live-patching=inline

  Only enable inlining, disable all other IPA optimization/analyses.
As a result, when patching a routine, all its callers need to be patches
as well.

-fease-live-patching=inline-clone

  Only enable inlining and all optimizations that internally create clone,
for example, cloning, ipa-sra, partial inlining, etc; disable all 
other IPA optimizations/analyses.
  As a result, when patching a routine, all its callers and its clones'
callers need to be patched as well. 

When -fease-live-patching specified without any value, the default value
is "inline-clone". 

B. an option to compute the impacted function lists and dump them for
live-patching users.  

-flive-patching-list={func_name|all}{,dump_func_name}

This option guides the compiler to compute the list of impacted routines for
live patching. It only has effect when it is combined with -fease-live-patching.

-flive-patching-list=func_name

compute the list of impacted routines for the routine "func_name" and dump it
into stdout.

-flive-patching-list=all

compute the list of impacted routines for all routines and dump them 
into stdout.

-flive-patching-list=func_name,dump_func_name

compute the list of impacted routines for the routine "func_name" and dump it
into the file "dump_func_name".

-flive-patching-list=all,dump_func_name

compute the list of impacted routines for all routines and dump them 
into the file "dump_func_name".

when -flive-patching-list is specified without any value, the default value is
"all", i.e, compute the lists of impacted routines for all rourints and dump 
them into stdout.

Re: [RFC] GCC support for live-patching

[Bernhard Reutner-Fischer]

On 18 October 2018 19:34:52 CEST, Qing Zhao <qing.zhao@oracle.com> wrote:

>A. an option to control GCC's IPA optimizations to provide a safe 
>compilation for live-patching purpose. At the same time, provides
>multiple-level control of patch code-size and run time performance 
>tradeoff. 
>
>-fease-live-patching={none|only-inline-static|inline|inline-clone}

s/-fease-live-patching/-flive-patching/g

please.
TIA

Re: [RFC] GCC support for live-patching

[Qing Zhao]

> On Oct 19, 2018, at 3:02 AM, Bernhard Reutner-Fischer <rep.dot.nop@gmail.com> wrote:
> 
> On 18 October 2018 19:34:52 CEST, Qing Zhao <qing.zhao@oracle.com> wrote:
> 
>> A. an option to control GCC's IPA optimizations to provide a safe 
>> compilation for live-patching purpose. At the same time, provides
>> multiple-level control of patch code-size and run time performance 
>> tradeoff. 
>> 
>> -fease-live-patching={none|only-inline-static|inline|inline-clone}
> 
> s/-fease-live-patching/-flive-patching/g

Okay.

Qing
> 
> please.
> TIA

Re: [RFC] GCC support for live-patching

[Alexandre Oliva]

On Oct 19, 2018, Qing Zhao <qing.zhao@oracle.com> wrote:

>> s/-fease-live-patching/-flive-patching/g

> Okay.

Now that there's no risk that my following joke will be mistaken as
serious, I'll suggest -facilitate-live-patching ;-)

-- 
Alexandre Oliva, freedom fighter   https://FSFLA.org/blogs/lxo
Be the change, be Free!         FSF Latin America board member
GNU Toolchain Engineer                Free Software Evangelist
Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe

Re: [RFC] GCC support for live-patching

[Andi Kleen]

Qing Zhao <qing.zhao@oracle.com> writes:

I think you first need to define the problem better.

> If we want to control the patch code size,

Why is it even a useful goal to limit patch code size?

Is it because you generate something manually and want to limit that
work, or is there some other reasons why patches cannot be as big as
needed?

If it's the first perhaps the better fix would be better tools
that automatically handle all IPA clones?

AFAIK there is nothing else in the linux kernel life patching at least
that would favour smaller patches over larger.

-And

Re: [RFC] GCC support for live-patching

[Qing Zhao]

> On Oct 19, 2018, at 8:45 AM, Andi Kleen <ak@linux.intel.com> wrote:
> 
> Qing Zhao <qing.zhao@oracle.com> writes:
> 
> I think you first need to define the problem better.
> 
>> If we want to control the patch code size,
> 
> Why is it even a useful goal to limit patch code size?

one of the initial major motivation of the whole task is for controlling the patch code size explosion due to too much inlining. 
please take a look at the original discussion on this:

https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00549.html 
https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00787.html

> 
> Is it because you generate something manually and want to limit that
> work,

I think that this is one of the reasons. 
and as mentioned in my writeup, the targeted users of this new functionality is for live-patching users who generate
patches by hand. 

please take a look at section 1. A study of Kernel live patching schemes.

in which, it explains that these new options are for helping live-patching users who create patches entirely by hand, including kernel
live-patching scheme kGraft, and one of our internal customers. 

the major reason is to control the code size explosion of manual patches. It’s the request from our internal customer. 

> or is there some other reasons why patches cannot be as big as
> needed?

debuggability is another reason.

As Jeff law already mentioned in a very previous email:

“Presumably one of the cases where this capability is really helpful is
things like ksplice.   If you have a function with global scope that has
been potentially inlined, then it's a lot harder track down those
inlining points at DTRT.

We ran into this internally when looking at hot patching some of the
spinlock code in the kernel.  It would have been real helpful if the
kernel had been compiled with this kind of option :-)

So conceptually I can see value in this kind of option.
“

> 
> If it's the first perhaps the better fix would be better tools
> that automatically handle all IPA clones?

I think that the current option 
-fease-live-patching=inline-clone  -flive-patching-list

should automatically ONLY enabling inline+clone optimization (disable all other ipa optimization/analyses at the same time) and generate the impacted function
list for each of the function.

is this what you want?

or you have other idea on this?

thanks.

Qing

> AFAIK there is nothing else in the linux kernel life patching at least
> that would favour smaller patches over larger.
> 
> -And

Re: [RFC] GCC support for live-patching

[Andi Kleen]

> > Is it because you generate something manually and want to limit that
> > work,
> 
> I think that this is one of the reasons. 
> and as mentioned in my writeup, the targeted users of this new functionality is for live-patching users who generate
> patches by hand. 

Ok just means they need better tooling.

> in which, it explains that these new options are for helping live-patching users who create patches entirely by hand, including kernel
> live-patching scheme kGraft, and one of our internal customers. 

It sounds to me the problem is not gcc here, but an inefficient scheme to create patches.

> the major reason is to control the code size explosion of manual patches. It’s the request from our internal customer. 

So essentially you want to disable inlining.

The Linux kernel code heavily relies on inlining to optimize constants
and remove unnecessary code paths.

For example I cannot even imagine how horrible the code for get/put/copy_*_user 
would be if you just disabled inlining on it. That's a fairly common 
coding pattern in core kernel code and it's not going away. 

I think the time that is spent here pessimizing code would be far better
spent creating better tools to create patches. There's a reason
why near all people stopped writing things manually in assembler and moved
to compilers. Same reasons should apply to patches.

> I think that the current option 
> -fease-live-patching=inline-clone  -flive-patching-list
> 
> should automatically ONLY enabling inline+clone optimization (disable all other ipa optimization/analyses at the same time) and generate the impacted function
> list for each of the function.

Dwarf2+ has all the information that is needed to find inlines and clones already.

e.g. systemtap and gdb and perf probes and most other debuggers support it fine
to find all copies of a given line.

I wrote parsing tools for that too and it's not too difficult to use.

-Andi

Re: [RFC] GCC support for live-patching

[Martin Jambor]

Hi Quing,

On Thu, Oct 18 2018, Qing Zhao wrote:
> Hi,
>
> After more detailed study of GCC’s IPA optimizations, further study of the current available kernel live patching schemes and 
> other live-patching user’s request, I came up with the following initial proposal in GCC to mainly support live-patching users who
> manually create patches. 
>
> Please take a look at the writeup, and let me know your opinions and suggestions.

thank you for writing down your thoughts.  My general note is that I'd
be wary with proposing (and implementing?) many options which would
eventually remain virtually unused with all the problems this entails.
I would concentrate on the few things that (kernel) live-patching
engineers really request and plan to routinely use now.  I do not think
that just because you can imagine a live-patching option might be useful
in some set of peculiar circumstances, it is worth having in GCC.  If we
find that we need more later, we can always add them.

More comments inline:

>
> thanks a lot.
>
> Qing
>
> ===========
>
> options to help live patching in GCC
>
> Qing Zhao
>
> 10/17/2018
> ================================================
>
> 0. The proposal:
>
> Provide two first class options in GCC to help live-patching users
> who manually generate patches. 
>
> A. an option to control GCC's IPA optimizations to provide a safe 
> compilation for live-patching purpose. At the same time, provides
> multiple-level control of patch code-size and run time performance 
> tradeoff. 
>
> -fease-live-patching={none|only-inline-static|inline|inline-clone}

I also agree that -flive-patching is much better.

> B. an option to compute the impacted function lists and dump them for
> live-patching users.  
>
> -flive-patching-list={func_name|all}{,dump_func_name}

Do you really think someone will ever want to use one function but not
the other?  Combining them into one would give us the flexibility to
change our mind in the future whether we want to identify all affected
functions or disable a particular analysis/transformation.

My preference would be to only have -flive-patching that would behave
like the default options for both options you propose, i.e. for each
function/symbol, dump to a file all other functions which are affected
in any way and disable any transformation where we cannot (easily) do
so.

...

> 3. Details of the proposal:
>
> What should GCC provide to live-patching users who manually create
> patches? 
>
> A. an option to control GCC's IPA optimizations to provide a safe 
> compilation for live-patching purpose. At the same time, provides
> multiple levels of patch code-size and run time performance tradeoff. 
>
> -fease-live-patching={none|only-inline-static|inline|inline-clone}
>
> -fease-live-patching=none
>
>   Disable all ipa optimizations/analyses in GCC.  As a result, any
> routine can be patched independently without impacting other routines.

How do you plan to reconcile this option with attribute always_inline?
We inline such functions even when you pass -fno-inline on the command
line and the description of the attribute says that "failure to inline
such a function is diagnosed as an error."  The only solution which I
can think of is to make combination of your proposed option and
always_inline attribute an unsupported one.  But (AFAIK) since Linux
kernel uses it everywhere, it would make -fease-live-patching=none
impossible to use with Linux kernel.

Additionally, I am quite certain that nobody will find the performance
degradation caused by not inlining anything at all in Linux kernel
acceptable in production.  It is not only my opinion, I have discussed
this with our live patching engineers and they agreed that if you find
out you have to patch a spinlock routine, you are very much... eh, to
put it mildly, you have just found yourself in an impossible situation.

So to conclude, I really think introducing this option is a bad idea, it
is impossible to define well and unlikely to be used by anybody.

>
> -fease-live-patching=only-inline-static
>
>   Only enable inlining of static functions, disable all other IPA 
> optimizations/analyses. As a result, when patching a static routine,
> all its callers need to be patches as well.

My general concern applies here as well, I still think the default
behavior is better for everybody.  But you might still convince Honza to
accept this because implementation-wise it is not difficult.

OTOH, I am no sure this is really defined well either, do we really want
say "static" functions and not functions with internal linkage?  My
concern is not only use with LTO but also functions in anonymous C++
namespaces.  I know Linux kernel does not really care for either but I
guess we should still be more careful when defining user facing options.

>
> -fease-live-patching=inline
>
>   Only enable inlining, disable all other IPA optimization/analyses.
> As a result, when patching a routine, all its callers need to be patches
> as well.

I am not convinced there is any merit in this behavior over the proposed
default but well, if you really think it is useful, it is easy to do.

> -fease-live-patching=inline-clone
>
>   Only enable inlining and all optimizations that internally create clone,
> for example, cloning, ipa-sra, partial inlining, etc; disable all 
> other IPA optimizations/analyses.
>
>   As a result, when patching a routine, all its callers and its clones'
> callers need to be patched as well. 

This would be my preferred (first) implementation (later on we may
discover we can do more, perhaps without involving clones) but I dislike
the name and description.  You really do not want to rely on internals
such as the notion of a "clone" when describing user-visible features.
As I have written above, I'd define it simply by dump all other affected
functions and disable any analysis/transformation for which this is not
easily possible.  This would give the user exactly what they want and
leave us with room to change (improve!) how we do stuff internally in
the future.

>
> When -fease-live-patching specified without any value, the default value
> is "inline-clone". 
>
> B. an option to compute the impacted function lists and dump them for
> live-patching users.  
>
> -flive-patching-list={func_name|all}{,dump_func_name}
>

Do you have any plans how to regularly test this works reliably?

Do you volunteer to implement this so that it works even when
-flive-patching is not given on the command line?  If not, I really
suggest combining these two options into one.

Can you please find out how just having the default for both options
would not work for you?  I would be good to know so that we can better
think about how to define the non-default behaviors.

Thanks,

Martin

Re: [RFC] GCC support for live-patching

[Qing Zhao]

> On Oct 22, 2018, at 7:17 AM, Martin Jambor <mjambor@suse.cz> wrote:
> 
> Hi Quing,
> 
> On Thu, Oct 18 2018, Qing Zhao wrote:
>> Hi,
>> 
>> After more detailed study of GCC’s IPA optimizations, further study of the current available kernel live patching schemes and 
>> other live-patching user’s request, I came up with the following initial proposal in GCC to mainly support live-patching users who
>> manually create patches. 
>> 
>> Please take a look at the writeup, and let me know your opinions and suggestions.
> 
> thank you for writing down your thoughts.  My general note is that I'd
> be wary with proposing (and implementing?) many options which would
> eventually remain virtually unused with all the problems this entails.
> I would concentrate on the few things that (kernel) live-patching
> engineers really request and plan to routinely use now.  I do not think
> that just because you can imagine a live-patching option might be useful
> in some set of peculiar circumstances, it is worth having in GCC.  If we
> find that we need more later, we can always add them.

Yes, I actually agree with you on this.

this is just an initial proposal, I’d like to make it as complete as possible in the beginning, then delete anything that are not necessary. 

> 
> More comments inline:
>> 
>> -fease-live-patching={none|only-inline-static|inline|inline-clone}
> 
> I also agree that -flive-patching is much better.
Okay.

> 
>> B. an option to compute the impacted function lists and dump them for
>> live-patching users.  
>> 
>> -flive-patching-list={func_name|all}{,dump_func_name}
> 
> Do you really think someone will ever want to use one function but not
> the other?  Combining them into one would give us the flexibility to
> change our mind in the future whether we want to identify all affected
> functions or disable a particular analysis/transformation.
> 
> My preference would be to only have -flive-patching that would behave
> like the default options for both options you propose, i.e. for each
> function/symbol, dump to a file all other functions which are affected
> in any way and disable any transformation where we cannot (easily) do
> so.

This works for me as well.

however, in addition to the above default behavior, we want an additional control:

-flive-patch=only-inline-static

to only enable inlining of static function for live patching. 

> 
> ...
> 
>> 3. Details of the proposal:
>> 
>> What should GCC provide to live-patching users who manually create
>> patches? 
>> 
>> A. an option to control GCC's IPA optimizations to provide a safe 
>> compilation for live-patching purpose. At the same time, provides
>> multiple levels of patch code-size and run time performance tradeoff. 
>> 
>> -fease-live-patching={none|only-inline-static|inline|inline-clone}
>> 
>> -fease-live-patching=none
>> 
>>  Disable all ipa optimizations/analyses in GCC.  As a result, any
>> routine can be patched independently without impacting other routines.
> 
> How do you plan to reconcile this option with attribute always_inline?
> We inline such functions even when you pass -fno-inline on the command
> line and the description of the attribute says that "failure to inline
> such a function is diagnosed as an error."  The only solution which I
> can think of is to make combination of your proposed option and
> always_inline attribute an unsupported one.  But (AFAIK) since Linux
> kernel uses it everywhere, it would make -fease-live-patching=none
> impossible to use with Linux kernel.

> 
> Additionally, I am quite certain that nobody will find the performance
> degradation caused by not inlining anything at all in Linux kernel
> acceptable in production.  It is not only my opinion, I have discussed
> this with our live patching engineers and they agreed that if you find
> out you have to patch a spinlock routine, you are very much... eh, to
> put it mildly, you have just found yourself in an impossible situation.
> 
> So to conclude, I really think introducing this option is a bad idea, it
> is impossible to define well and unlikely to be used by anybody.

since no one will use this sub-option, we can just delete it from the list.

> 
>> 
>> -fease-live-patching=only-inline-static
>> 
>>  Only enable inlining of static functions, disable all other IPA 
>> optimizations/analyses. As a result, when patching a static routine,
>> all its callers need to be patches as well.
> 
> My general concern applies here as well, I still think the default
> behavior is better for everybody.  But you might still convince Honza to
> accept this because implementation-wise it is not difficult.
> 
> OTOH, I am no sure this is really defined well either, do we really want
> say "static" functions and not functions with internal linkage?  My
> concern is not only use with LTO but also functions in anonymous C++
> namespaces.  I know Linux kernel does not really care for either but I
> guess we should still be more careful when defining user facing options.

this is a functionality that we want to keep: only inlining static functions for 
live patch. No LTO or C++ will be involved. 
> 
>> 
>> -fease-live-patching=inline
>> 
>>  Only enable inlining, disable all other IPA optimization/analyses.
>> As a result, when patching a routine, all its callers need to be patches
>> as well.
> 
> I am not convinced there is any merit in this behavior over the proposed
> default but well, if you really think it is useful, it is easy to do.

We can simply delete this from the list if no one will use it.
> 
>> -fease-live-patching=inline-clone
>> 
>>  Only enable inlining and all optimizations that internally create clone,
>> for example, cloning, ipa-sra, partial inlining, etc; disable all 
>> other IPA optimizations/analyses.
>> 
>>  As a result, when patching a routine, all its callers and its clones'
>> callers need to be patched as well. 
> 
> This would be my preferred (first) implementation (later on we may
> discover we can do more, perhaps without involving clones)

what’s you mean by “without involving clones”? could explain this more?

> but I dislike
> the name and description.  You really do not want to rely on internals
> such as the notion of a "clone" when describing user-visible features.
> As I have written above, I'd define it simply by dump all other affected
> functions and disable any analysis/transformation for which this is not
> easily possible.  This would give the user exactly what they want and
> leave us with room to change (improve!) how we do stuff internally in
> the future.

if there is only one level of control for -flive-patching as in your mind,  it’s Okay,

the issue here is:   in addition to the default control of -flive-patching,  we want
another level of control -flive-patching=only-inline-static,  therefore, we have to
give names for different level of controls. 

do you have suggestions on the suboptions:

-flive-patching=only-inline-static.  ====> ???
-flive-patching=inline-clone.   =====>???

> 
>> 
>> When -fease-live-patching specified without any value, the default value
>> is "inline-clone". 
>> 
>> B. an option to compute the impacted function lists and dump them for
>> live-patching users.  
>> 
>> -flive-patching-list={func_name|all}{,dump_func_name}
>> 
> 
> Do you have any plans how to regularly test this works reliably?
> 
> Do you volunteer to implement this so that it works even when
> -flive-patching is not given on the command line?

This should be very simple to be implemented, I think. If  -flive-patching is not present,
-flive-patching-list will NOT have any effect. 

-flive-patching-list is a on/off for the user to dump the impacted functions list.  

>  If not, I really
> suggest combining these two options into one.


So, you mean, for the live-patching users,  they do not need a ON/OFF to dump the impacted functions list, they want
the impacted functions list by default?


> 
> Can you please find out how just having the default for both options
> would not work for you?  I would be good to know so that we can better
> think about how to define the non-default behaviors.

As I mentioned in the above,  in addition to the default behavior, we want the following 

-flive-patching=only-inline-static

Thanks.

Qing
> 
> Thanks,
> 
> Martin

Re: [RFC] GCC support for live-patching

[Miroslav Benes]

[-- Attachment #1: Type: text/plain, Size: 8431 bytes --]

On Thu, 18 Oct 2018, Qing Zhao wrote:

> Hi,
> 
> After more detailed study of GCC’s IPA optimizations, further study of the current available kernel live patching schemes and 
> other live-patching user’s request, I came up with the following initial proposal in GCC to mainly support live-patching users who
> manually create patches. 
> 
> Please take a look at the writeup, and let me know your opinions and suggestions.

Hi,

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 here at SUSE, we use kGraft 
and we prepare everything manually (compared to kpatch and ksplice).

[...] 

> 1. A study of Kernel live patching schemes.
> 
> Three major kernel live patching tools:  https://lwn.net/Articles/734765/
> 
> * ksplice:   http://www.ksplice.com/doc/ksplice.pdf
> * kpatch:    https://lwn.net/Articles/597123/
>             https://github.com/dynup/kpatch
> * kGraft:    
> https://pdfs.semanticscholar.org/presentation/af4c/895aa3fef0cc2b501317aaec9d91ba2d704c.pdf
> 
> In the above, ksplice and kpatch can automatically generate binary patches 
> as following:
> 
>    * a collection of tools which convert a source diff patch to a patch
> module. They work by compiling the kernel both with and without the source
> patch, comparing the binaries, and generating a binary patch module which 
> includes new binary versions of the functions to be replaced.
> 
> on the other hand, kGraft offers a way to create patches entirely by hand. 
> The source of the patch is a single C file, easy to review, easy to
> maintain. 
> 
> In addition to kGraft, there are other live patching tools that prefer
> creating patches by hand for the similar reason. 
> 
> The compiler support is mainly for the above live patching tools that create 
> patches entirely by hand. the major purpose is:
> 
>  * control patch code size and debug complexity;
>  * keep good run time performance;
> 
> 2. the major problems of compiler in live patching:
> 
> For the live patching schemes that create patches by hand, when patching 
> one function, there might a list of functions that will be impacted by 
> this patched function due to compiler optimization/analyses (mainly IPA
> optimization/analyses), a complete patch will include the patched function
> and all impacted functions. Usually, there are two major factors to be
> considered in such live patching schemes:
> 
>  * patch code size, one major factor is the length of the list 
> of impacted functions;
>  * run time performance.
> 
> If we want to control the patch code size, to make the list of impacted 
> functions minimum, we have to disable corresponding compiler optimizations 
> as much as possible.

Andi already talked about it and I, too, do not understand your worry 
about patch code size. First, it has never been so bad here. Yes, 
sometimes the function closure gets bigger due to optimizations and 
inlining. I've considered it as nothing else than a lack of better 
tooling, because it is indeed something which could be improved a lot. 
Nicolai (CCed) works on a potential solution. It is also one of the topics 
at LPC miniconf in Vancouver.

Second, the idea to disable inlining would not fly at SUSE. I can't 
imagine to even propose it. The kernel heavily relies on the feature. The 
optimizations are a different story and some of those certainly could be 
disabled with no harm caused.

So let me ask, what is your motivation behind this? Is there a real 
problem you're trying to solve? It may have been mentioned somewhere and I 
missed it.

> On the other hand, in order to keep good run time performance, we need to 
> keep the compiler optimization as much as possible. 
> 
> So, there should be some tradeoff between these two factors. 
> 
> The following are two major categories of compiler optimizations 
> we should considered:
> 
>  A. compiler optimizations/analyses that extract ipa info from
> a routine's body, and use such info to guide other optimization.
> 
> Since the body of the routine might be changed for live patching, 
> the ipa info extracted from the body of the routine also changes,
> as a result, all the routines that directly or indirectly utilize 
> the ipa info from this routine are in the list of the impacted 
> routines.  
> 
> Most of the IPA analyses and optimization belong to this category. 
> 
> Although theoretically the impacted routine list from such ipa 
> phases could be computed, the list might be huge. Such huge list
> of impacted routine might explode the patch code size too much. 
> 
> Therefore, it might be more pratical to just completely disable such
> ipa optimizations/analyses.
> 
>  B. Inlining, and all optimizaitons that internally create clone. 
> for example, cloning, ipa-sra, partial inlining, etc.
> We can track the effect and impacted routine of such optimization 
> easily. 
> Such kind of optimization could be kept, but the compiler
> should provide the list of impacted functions if a routine need to 
> be patched.
> 
> There is patch code size explosion potential even with only enabling
> inlining and cloning for live patching. Users need a way to control 
> the inlining and cloning in order to control the code size explosion 
> and complexity of debugging.
> 
> 3. Details of the proposal:

This sounds awfully complicated. Especially when there is a dumping option 
in GCC thanks to Martin. What information do you miss there? We could 
improve the analysis tool. So far, it has given us all the info we need.

In the end, I'd be more than happy with what has been proposed in this 
thread by the others. To have a way to guarantee that GCC would not apply 
an optimization that could potentially destroy our effort to livepatch a 
running system.

> What should GCC provide to live-patching users who manually create
> patches? 
> 
> A. an option to control GCC's IPA optimizations to provide a safe 
> compilation for live-patching purpose. At the same time, provides
> multiple levels of patch code-size and run time performance tradeoff. 
> 
> -fease-live-patching={none|only-inline-static|inline|inline-clone}
> 
> -fease-live-patching=none
> 
>   Disable all ipa optimizations/analyses in GCC.  As a result, any
> routine can be patched independently without impacting other routines.
> 
> -fease-live-patching=only-inline-static
> 
>   Only enable inlining of static functions, disable all other IPA 
> optimizations/analyses. As a result, when patching a static routine,
> all its callers need to be patches as well.
> 
> -fease-live-patching=inline
> 
>   Only enable inlining, disable all other IPA optimization/analyses.
> As a result, when patching a routine, all its callers need to be patches
> as well.
> 
> -fease-live-patching=inline-clone
> 
>   Only enable inlining and all optimizations that internally create clone,
> for example, cloning, ipa-sra, partial inlining, etc; disable all 
> other IPA optimizations/analyses.
>   As a result, when patching a routine, all its callers and its clones'
> callers need to be patched as well. 
> 
> When -fease-live-patching specified without any value, the default value
> is "inline-clone". 
> 
> B. an option to compute the impacted function lists and dump them for
> live-patching users.  
> 
> -flive-patching-list={func_name|all}{,dump_func_name}
> 
> This option guides the compiler to compute the list of impacted routines for
> live patching. It only has effect when it is combined with -fease-live-patching.
> 
> -flive-patching-list=func_name
> 
> compute the list of impacted routines for the routine "func_name" and dump it
> into stdout.
> 
> -flive-patching-list=all
> 
> compute the list of impacted routines for all routines and dump them 
> into stdout.
> 
> -flive-patching-list=func_name,dump_func_name
> 
> compute the list of impacted routines for the routine "func_name" and dump it
> into the file "dump_func_name".
> 
> -flive-patching-list=all,dump_func_name
> 
> compute the list of impacted routines for all routines and dump them 
> into the file "dump_func_name".
> 
> when -flive-patching-list is specified without any value, the default value is
> "all", i.e, compute the lists of impacted routines for all rourints and dump 
> them into stdout.

Thanks,
Miroslav

Re: [RFC] GCC support for live-patching

[Qing Zhao]

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 here at SUSE, we use kGraft 
> and we prepare everything manually (compared to kpatch and ksplice).

One question here,  what’s the major benefit to prepare the patches manually? 
> 
>> 1. A study of Kernel live patching schemes.
>> 
>> Three major kernel live patching tools:  https://lwn.net/Articles/734765/
>> 
>> * ksplice:   http://www.ksplice.com/doc/ksplice.pdf
>> * kpatch:    https://lwn.net/Articles/597123/
>>            https://github.com/dynup/kpatch
>> * kGraft:    
>> https://pdfs.semanticscholar.org/presentation/af4c/895aa3fef0cc2b501317aaec9d91ba2d704c.pdf
>> 
>> In the above, ksplice and kpatch can automatically generate binary patches 
>> as following:
>> 
>>   * a collection of tools which convert a source diff patch to a patch
>> module. They work by compiling the kernel both with and without the source
>> patch, comparing the binaries, and generating a binary patch module which 
>> includes new binary versions of the functions to be replaced.
>> 
>> on the other hand, kGraft offers a way to create patches entirely by hand. 
>> The source of the patch is a single C file, easy to review, easy to
>> maintain. 
>> 
>> In addition to kGraft, there are other live patching tools that prefer
>> creating patches by hand for the similar reason. 
>> 
>> The compiler support is mainly for the above live patching tools that create 
>> patches entirely by hand. the major purpose is:
>> 
>> * control patch code size and debug complexity;
>> * keep good run time performance;
>> 
>> 2. the major problems of compiler in live patching:
>> 
>> For the live patching schemes that create patches by hand, when patching 
>> one function, there might a list of functions that will be impacted by 
>> this patched function due to compiler optimization/analyses (mainly IPA
>> optimization/analyses), a complete patch will include the patched function
>> and all impacted functions. Usually, there are two major factors to be
>> considered in such live patching schemes:
>> 
>> * patch code size, one major factor is the length of the list 
>> of impacted functions;
>> * run time performance.
>> 
>> If we want to control the patch code size, to make the list of impacted 
>> functions minimum, we have to disable corresponding compiler optimizations 
>> as much as possible.
> 
> Andi already talked about it and I, too, do not understand your worry 
> about patch code size. First, it has never been so bad here. Yes, 
> sometimes the function closure gets bigger due to optimizations and 
> inlining. I've considered it as nothing else than a lack of better 
> tooling, because it is indeed something which could be improved a lot. 
> Nicolai (CCed) works on a potential solution. It is also one of the topics 
> at LPC miniconf in Vancouver.
> 
> Second, the idea to disable inlining would not fly at SUSE. I can't 
> imagine to even propose it. The kernel heavily relies on the feature. The 
> optimizations are a different story and some of those certainly could be 
> disabled with no harm caused.
> 
> So let me ask, what is your motivation behind this? Is there a real 
> problem you're trying to solve? It may have been mentioned somewhere and I 
> missed it.

the major functionality we want is:   to Only enable static inlining for live patching for one 
of our internal customers.   the major purpose is to control the patch code size explosion and
debugging complexity due to too much inlining of global functions for the specific application.

therefore, I proposed the multiple level of control for -flive-patching to satisfy multiple request from 
different users. 

So far, from the feedback, I see that among the 4 levels of control,   none, only-inline-static, inline,
and inline-clone,   “none” and “inline” are NOT needed at all.

however,  -flive-patching = [only-inline-static | inline-clone] are necessary.

> 
>> On the other hand, in order to keep good run time performance, we need to 
>> keep the compiler optimization as much as possible. 
>> 
>> So, there should be some tradeoff between these two factors. 
>> 
>> The following are two major categories of compiler optimizations 
>> we should considered:
>> 
>> A. compiler optimizations/analyses that extract ipa info from
>> a routine's body, and use such info to guide other optimization.
>> 
>> Since the body of the routine might be changed for live patching, 
>> the ipa info extracted from the body of the routine also changes,
>> as a result, all the routines that directly or indirectly utilize 
>> the ipa info from this routine are in the list of the impacted 
>> routines.  
>> 
>> Most of the IPA analyses and optimization belong to this category. 
>> 
>> Although theoretically the impacted routine list from such ipa 
>> phases could be computed, the list might be huge. Such huge list
>> of impacted routine might explode the patch code size too much. 
>> 
>> Therefore, it might be more pratical to just completely disable such
>> ipa optimizations/analyses.
>> 
>> B. Inlining, and all optimizaitons that internally create clone. 
>> for example, cloning, ipa-sra, partial inlining, etc.
>> We can track the effect and impacted routine of such optimization 
>> easily. 
>> Such kind of optimization could be kept, but the compiler
>> should provide the list of impacted functions if a routine need to 
>> be patched.
>> 
>> There is patch code size explosion potential even with only enabling
>> inlining and cloning for live patching. Users need a way to control 
>> the inlining and cloning in order to control the code size explosion 
>> and complexity of debugging.
>> 
>> 3. Details of the proposal:
> 
> This sounds awfully complicated. Especially when there is a dumping option 
> in GCC thanks to Martin. What information do you miss there? We could 
> improve the analysis tool. So far, it has given us all the info we need.

Yes, it’s TRUE that the tool Martin wrote should serve the same purpose. nothing new from this
new GCC option -flive-patch-list compared to Martin’s tool.

However,  by simply adding this new GCC’s option, we can simplify the whole procedure for helping
live-patching. by only running  GCC with the new added options once, we can get the impacted function list
at the same time. No need to run another tool anymore.   

this is the major benefit from this new option.

anyway, if most of the people think that this new option is not necessary, I am fine to delete it. 
> 
> In the end, I'd be more than happy with what has been proposed in this 
> thread by the others. To have a way to guarantee that GCC would not apply 
> an optimization that could potentially destroy our effort to livepatch a 
> running system.

So, the major functionality you want from GCC is:

-flive-patching=inline-clone

 Only enable inlining and all optimizations that internally create clone,
for example, cloning, ipa-sra, partial inlining, etc; disable all 
other IPA optimizations/analyses.

As a result, when patching a routine, all its callers and its clones’
callers need to be patched as well. 

?

thanks.

Qing

Re: [RFC] GCC support for live-patching

[Miroslav Benes]

[-- Attachment #1: Type: text/plain, Size: 8554 bytes --]

On Mon, 22 Oct 2018, Qing Zhao wrote:

> 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 here at SUSE, we use kGraft 
> > and we prepare everything manually (compared to kpatch and ksplice).
> 
> 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 implement 
tricky hacks easily by hand if needed.
 
> >> 1. A study of Kernel live patching schemes.
> >> 
> >> Three major kernel live patching tools:  https://lwn.net/Articles/734765/
> >> 
> >> * ksplice:   http://www.ksplice.com/doc/ksplice.pdf
> >> * kpatch:    https://lwn.net/Articles/597123/
> >>            https://github.com/dynup/kpatch
> >> * kGraft:    
> >> https://pdfs.semanticscholar.org/presentation/af4c/895aa3fef0cc2b501317aaec9d91ba2d704c.pdf
> >> 
> >> In the above, ksplice and kpatch can automatically generate binary patches 
> >> as following:
> >> 
> >>   * a collection of tools which convert a source diff patch to a patch
> >> module. They work by compiling the kernel both with and without the source
> >> patch, comparing the binaries, and generating a binary patch module which 
> >> includes new binary versions of the functions to be replaced.
> >> 
> >> on the other hand, kGraft offers a way to create patches entirely by hand. 
> >> The source of the patch is a single C file, easy to review, easy to
> >> maintain. 
> >> 
> >> In addition to kGraft, there are other live patching tools that prefer
> >> creating patches by hand for the similar reason. 
> >> 
> >> The compiler support is mainly for the above live patching tools that create 
> >> patches entirely by hand. the major purpose is:
> >> 
> >> * control patch code size and debug complexity;
> >> * keep good run time performance;
> >> 
> >> 2. the major problems of compiler in live patching:
> >> 
> >> For the live patching schemes that create patches by hand, when patching 
> >> one function, there might a list of functions that will be impacted by 
> >> this patched function due to compiler optimization/analyses (mainly IPA
> >> optimization/analyses), a complete patch will include the patched function
> >> and all impacted functions. Usually, there are two major factors to be
> >> considered in such live patching schemes:
> >> 
> >> * patch code size, one major factor is the length of the list 
> >> of impacted functions;
> >> * run time performance.
> >> 
> >> If we want to control the patch code size, to make the list of impacted 
> >> functions minimum, we have to disable corresponding compiler optimizations 
> >> as much as possible.
> > 
> > Andi already talked about it and I, too, do not understand your worry 
> > about patch code size. First, it has never been so bad here. Yes, 
> > sometimes the function closure gets bigger due to optimizations and 
> > inlining. I've considered it as nothing else than a lack of better 
> > tooling, because it is indeed something which could be improved a lot. 
> > Nicolai (CCed) works on a potential solution. It is also one of the topics 
> > at LPC miniconf in Vancouver.
> > 
> > Second, the idea to disable inlining would not fly at SUSE. I can't 
> > imagine to even propose it. The kernel heavily relies on the feature. The 
> > optimizations are a different story and some of those certainly could be 
> > disabled with no harm caused.
> > 
> > So let me ask, what is your motivation behind this? Is there a real 
> > problem you're trying to solve? It may have been mentioned somewhere and I 
> > missed it.
> 
> the major functionality we want is:   to Only enable static inlining for live patching for one 
> of our internal customers.   the major purpose is to control the patch code size explosion and
> debugging complexity due to too much inlining of global functions for the specific application.

I hoped for more details, but ok.
 
> therefore, I proposed the multiple level of control for -flive-patching to satisfy multiple request from 
> different users. 
> 
> So far, from the feedback, I see that among the 4 levels of control,   none, only-inline-static, inline,
> and inline-clone,   “none” and “inline” are NOT needed at all.
> 
> however,  -flive-patching = [only-inline-static | inline-clone] are necessary.
> 
> > 
> >> On the other hand, in order to keep good run time performance, we need to 
> >> keep the compiler optimization as much as possible. 
> >> 
> >> So, there should be some tradeoff between these two factors. 
> >> 
> >> The following are two major categories of compiler optimizations 
> >> we should considered:
> >> 
> >> A. compiler optimizations/analyses that extract ipa info from
> >> a routine's body, and use such info to guide other optimization.
> >> 
> >> Since the body of the routine might be changed for live patching, 
> >> the ipa info extracted from the body of the routine also changes,
> >> as a result, all the routines that directly or indirectly utilize 
> >> the ipa info from this routine are in the list of the impacted 
> >> routines.  
> >> 
> >> Most of the IPA analyses and optimization belong to this category. 
> >> 
> >> Although theoretically the impacted routine list from such ipa 
> >> phases could be computed, the list might be huge. Such huge list
> >> of impacted routine might explode the patch code size too much. 
> >> 
> >> Therefore, it might be more pratical to just completely disable such
> >> ipa optimizations/analyses.
> >> 
> >> B. Inlining, and all optimizaitons that internally create clone. 
> >> for example, cloning, ipa-sra, partial inlining, etc.
> >> We can track the effect and impacted routine of such optimization 
> >> easily. 
> >> Such kind of optimization could be kept, but the compiler
> >> should provide the list of impacted functions if a routine need to 
> >> be patched.
> >> 
> >> There is patch code size explosion potential even with only enabling
> >> inlining and cloning for live patching. Users need a way to control 
> >> the inlining and cloning in order to control the code size explosion 
> >> and complexity of debugging.
> >> 
> >> 3. Details of the proposal:
> > 
> > This sounds awfully complicated. Especially when there is a dumping option 
> > in GCC thanks to Martin. What information do you miss there? We could 
> > improve the analysis tool. So far, it has given us all the info we need.
> 
> Yes, it’s TRUE that the tool Martin wrote should serve the same purpose. nothing new from this
> new GCC option -flive-patch-list compared to Martin’s tool.
> 
> However,  by simply adding this new GCC’s option, we can simplify the whole procedure for helping
> live-patching. by only running  GCC with the new added options once, we can get the impacted function list
> at the same time. No need to run another tool anymore.   

I probably do not understand completely. I thought that using the 
option you would "preprocess" everything during the kernel build and then 
you'd need a tool to get the impacted function list for a given function. 
In that case, Martin's work is more than sufficient.

Now I think you meant to run GCC with a given function, build everything 
and the list. Iteratively for every to-be-patched function. It does not 
sound better to me.
 
> this is the major benefit from this new option.
> 
> anyway, if most of the people think that this new option is not necessary, I am fine to delete it. 
> > 
> > In the end, I'd be more than happy with what has been proposed in this 
> > thread by the others. To have a way to guarantee that GCC would not apply 
> > an optimization that could potentially destroy our effort to livepatch a 
> > running system.
> 
> So, the major functionality you want from GCC is:
> 
> -flive-patching=inline-clone
> 
>  Only enable inlining and all optimizations that internally create clone,
> for example, cloning, ipa-sra, partial inlining, etc; disable all 
> other IPA optimizations/analyses.
> 
> As a result, when patching a routine, all its callers and its clones’
> callers need to be patched as well. 
> 
> ?

I cannot decide that. Perhaps. Josh called this hypothetical option 
-fpreserve-function-abi, which seems self-explaining to me.

Regards,
Miroslav

Re: [RFC] GCC support for live-patching

[Qing Zhao]

> On Oct 23, 2018, at 4:11 AM, Miroslav Benes <mbenes@suse.cz> 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 implement 
> tricky hacks easily by hand if needed.

Okay, I see. 

another question here:

From my understanding of the live patching creation from Nicolai’s email, the patch includes:

1. initial patched functions;
2. all the callers of any patched function if it’s been inlined/cloned/optimized;
3. recursively copy any needed cpp macro, type, or
  functions definition and add references to data objects with static
  storage duration.

during review and maintain procedure, are all the above 3 need to be reviewed and maintained?

>>> 
>>> So let me ask, what is your motivation behind this? Is there a real 
>>> problem you're trying to solve? It may have been mentioned somewhere and I 
>>> missed it.
>> 
>> the major functionality we want is:   to Only enable static inlining for live patching for one 
>> of our internal customers.   the major purpose is to control the patch code size explosion and
>> debugging complexity due to too much inlining of global functions for the specific application.
> 
> I hoped for more details, but ok.
at this time, this is the details I have. I can ask more if more details are needed.

> 
>> therefore, I proposed the multiple level of control for -flive-patching to satisfy multiple request from 
>> different users. 
>> 
>> So far, from the feedback, I see that among the 4 levels of control,   none, only-inline-static, inline,
>> and inline-clone,   “none” and “inline” are NOT needed at all.
>> 
>> however,  -flive-patching = [only-inline-static | inline-clone] are necessary.
>> 
>>> 
>>>> 
>>>> 3. Details of the proposal:
>>> 
>>> This sounds awfully complicated. Especially when there is a dumping option 
>>> in GCC thanks to Martin. What information do you miss there? We could 
>>> improve the analysis tool. So far, it has given us all the info we need.
>> 
>> Yes, it’s TRUE that the tool Martin wrote should serve the same purpose. nothing new from this
>> new GCC option -flive-patch-list compared to Martin’s tool.
>> 
>> However,  by simply adding this new GCC’s option, we can simplify the whole procedure for helping
>> live-patching. by only running  GCC with the new added options once, we can get the impacted function list
>> at the same time. No need to run another tool anymore.   
> 
> I probably do not understand completely. I thought that using the 
> option you would "preprocess" everything during the kernel build and then 
> you'd need a tool to get the impacted function list for a given function. 
> In that case, Martin's work is more than sufficient.
> 
> Now I think you meant to run GCC with a given function, build everything 
> and the list. Iteratively for every to-be-patched function. It does not 
> sound better to me.

there might be misunderstanding among us for this part.  Let me explain my understanding first:

1. with martin’s tool, there are two steps to get the impacted function list for patched functions:

    Step1,  build kernel with GCC with -fdump-ipa-clones + a bunch of options to disable bunch of ipa optimizations. ;
    Step2,  using the tool kgraft-ipa-analysis.py to analyze the dumped file from step1 to report the impacted function list.

2. with the new functionality of the GCC proposed in this proposal, -flive-patching -flive-patch-list

    Step1,  build kernel with GCC with  -flive-patching -flive-patch-list
    
    then gcc will automatically disable the unsafe ipa optimizations and report the impacted function list with the safe ipa optimizations. 

compare 1 and 2,  I think that 2 is better and much more convenient than 1. another benefit from 2 is:

if later we want more ipa optimization to be On for live-patching for the runtime performance purpose, we can expand it easily to include those
ipa optimization and at the same time report the additional impacted function list with the new ipa optimizations. 

however, for 1,  this will be not easy to be extended. 

do I miss anything here?

> 
>> this is the major benefit from this new option.
>> 
>> anyway, if most of the people think that this new option is not necessary, I am fine to delete it. 
>>> 
>>> In the end, I'd be more than happy with what has been proposed in this 
>>> thread by the others. To have a way to guarantee that GCC would not apply 
>>> an optimization that could potentially destroy our effort to livepatch a 
>>> running system.
>> 
>> So, the major functionality you want from GCC is:
>> 
>> -flive-patching=inline-clone
>> 
>> Only enable inlining and all optimizations that internally create clone,
>> for example, cloning, ipa-sra, partial inlining, etc; disable all 
>> other IPA optimizations/analyses.
>> 
>> As a result, when patching a routine, all its callers and its clones’
>> callers need to be patched as well. 
>> 
>> ?
> 
> I cannot decide that. Perhaps. Josh called this hypothetical option 
> -fpreserve-function-abi, which seems self-explaining to me.

in the option -fpreserve-function-abi, will inlining and cloning are enabled by default?

thanks.

Qing
> 
> Regards,
> Miroslav

Re: [RFC] GCC support for live-patching

[Miroslav Benes]

[-- Attachment #1: Type: text/plain, Size: 5995 bytes --]

On Tue, 23 Oct 2018, Qing Zhao wrote:

> 
> > On Oct 23, 2018, at 4:11 AM, Miroslav Benes <mbenes@suse.cz> 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 implement 
> > tricky hacks easily by hand if needed.
> 
> Okay, I see. 
> 
> another question here:
> 
> From my understanding of the live patching creation from Nicolai’s email, the patch includes:
> 
> 1. initial patched functions;
> 2. all the callers of any patched function if it’s been inlined/cloned/optimized;
> 3. recursively copy any needed cpp macro, type, or
>   functions definition and add references to data objects with static
>   storage duration.
> 
> during review and maintain procedure, are all the above 3 need to be reviewed and maintained?

Either I do not understand, or this is mainly a process question. It is 
really up to you if you want to review it or not. Possibility is the 
imporant word here. Source based approach (which I originally replied to 
and confused it with manual preparation) allows you to do it.
 
> >>> 
> >>> So let me ask, what is your motivation behind this? Is there a real 
> >>> problem you're trying to solve? It may have been mentioned somewhere and I 
> >>> missed it.
> >> 
> >> the major functionality we want is:   to Only enable static inlining for live patching for one 
> >> of our internal customers.   the major purpose is to control the patch code size explosion and
> >> debugging complexity due to too much inlining of global functions for the specific application.
> > 
> > I hoped for more details, but ok.
> at this time, this is the details I have. I can ask more if more details are needed.
> 
> > 
> >> therefore, I proposed the multiple level of control for -flive-patching to satisfy multiple request from 
> >> different users. 
> >> 
> >> So far, from the feedback, I see that among the 4 levels of control,   none, only-inline-static, inline,
> >> and inline-clone,   “none” and “inline” are NOT needed at all.
> >> 
> >> however,  -flive-patching = [only-inline-static | inline-clone] are necessary.
> >> 
> >>> 
> >>>> 
> >>>> 3. Details of the proposal:
> >>> 
> >>> This sounds awfully complicated. Especially when there is a dumping option 
> >>> in GCC thanks to Martin. What information do you miss there? We could 
> >>> improve the analysis tool. So far, it has given us all the info we need.
> >> 
> >> Yes, it’s TRUE that the tool Martin wrote should serve the same purpose. nothing new from this
> >> new GCC option -flive-patch-list compared to Martin’s tool.
> >> 
> >> However,  by simply adding this new GCC’s option, we can simplify the whole procedure for helping
> >> live-patching. by only running  GCC with the new added options once, we can get the impacted function list
> >> at the same time. No need to run another tool anymore.   
> > 
> > I probably do not understand completely. I thought that using the 
> > option you would "preprocess" everything during the kernel build and then 
> > you'd need a tool to get the impacted function list for a given function. 
> > In that case, Martin's work is more than sufficient.
> > 
> > Now I think you meant to run GCC with a given function, build everything 
> > and the list. Iteratively for every to-be-patched function. It does not 
> > sound better to me.
> 
> there might be misunderstanding among us for this part.  Let me explain my understanding first:
> 
> 1. with martin’s tool, there are two steps to get the impacted function list for patched functions:
> 
>     Step1,  build kernel with GCC with -fdump-ipa-clones + a bunch of options to disable bunch of ipa optimizations. ;
>     Step2,  using the tool kgraft-ipa-analysis.py to analyze the dumped file from step1 to report the impacted function list.
> 
> 2. with the new functionality of the GCC proposed in this proposal, -flive-patching -flive-patch-list
> 
>     Step1,  build kernel with GCC with  -flive-patching -flive-patch-list
>     
>     then gcc will automatically disable the unsafe ipa optimizations and report the impacted function list with the safe ipa optimizations. 
> 
> compare 1 and 2,  I think that 2 is better and much more convenient than 1. another benefit from 2 is:
> 
> if later we want more ipa optimization to be On for live-patching for the runtime performance purpose, we can expand it easily to include those
> ipa optimization and at the same time report the additional impacted function list with the new ipa optimizations. 
> 
> however, for 1,  this will be not easy to be extended. 
> 
> do I miss anything here?

No, thanks for clearing it up.

> > 
> >> this is the major benefit from this new option.
> >> 
> >> anyway, if most of the people think that this new option is not necessary, I am fine to delete it. 
> >>> 
> >>> In the end, I'd be more than happy with what has been proposed in this 
> >>> thread by the others. To have a way to guarantee that GCC would not apply 
> >>> an optimization that could potentially destroy our effort to livepatch a 
> >>> running system.
> >> 
> >> So, the major functionality you want from GCC is:
> >> 
> >> -flive-patching=inline-clone
> >> 
> >> Only enable inlining and all optimizations that internally create clone,
> >> for example, cloning, ipa-sra, partial inlining, etc; disable all 
> >> other IPA optimizations/analyses.
> >> 
> >> As a result, when patching a routine, all its callers and its clones’
> >> callers need to be patched as well. 
> >> 
> >> ?
> > 
> > I cannot decide that. Perhaps. Josh called this hypothetical option 
> > -fpreserve-function-abi, which seems self-explaining to me.
> 
> in the option -fpreserve-function-abi, will inlining and cloning are enabled by default?

I think it more or less corresponds to your inline-clone.

Miroslav

Re: [RFC] GCC support for live-patching

[Nicolai Stange]

Hi,

Qing Zhao <qing.zhao@oracle.com> writes:

>> 
>> 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 here at SUSE, we use kGraft 
>> and we prepare everything manually (compared to kpatch and ksplice).
>
> One question here,  what’s the major benefit to prepare the patches manually? 

There is none. We here at SUSE prefer the source based approach (as
opposed to binary diff) for a number of reasons and the manual live
patch creation is simply a consequence of not having any tooling for
this yet.


For reference, source based live patch creation involves the following
steps:

1. Determine the initial set of to be patched functions:
   a.) Inspect the upstream diff for the fix in question, add
       any touched functions to the initial set.
   b.) For each function in the initial set, check whether it has been
       inlined/cloned/optimized and if so, add all its callers to the
       initial set.  Repeat until the initial set has stabilized.

2. Copy & paste the initial set over to the new live patch sources.

3. Make it compile, i.e. recursively copy any needed cpp macro, type, or
   functions definition and add references to data objects with static
   storage duration.
   The rules are:
   a.) For data objects with static storage duration, a reference to the
       original must always be made. (If the symbol is EXPORT()ed, then
       fine. Otherwise, for kGraft, this involves a kallsyms lookup at
       patch module load time, for upstream kernel live patching, this
       has been solved with those '.klp....' relocations).
   b.) If a called function is available as a symbol from either vmlinux
       or some (usually the patched) module, do not copy the definition,
       but add a reference to it, just as in a.).
   c.) If a type, cpp macro or (usually inlined) function is provided by
       some "public" header in <linux-tree>/include/, include that
       rather than copying the definition.  Counterexample: Non-public
       header outside of include/ like
       e.g. <linux-tree>/fs/btrfs/qgroup.h.
   d.) Otherwise copy the definition to the live patch module sources.

Rule 3b is not strictly necessary, but it helps in reducing the live
patch code size which is a factor with _manual_ live patch creation.

For 1b.), we need help from GCC. Namely, we want to know when some
functions has been optimized and we want it to disable any of those IPA
optimization it (currently) isn't capable to report properly.

Step 3.) is a bit tedious sometimes TBH and yes, w/o any tooling in
place, patch size would be a valid point. However, I'm currently working
on that and I'm optimistic that I'll have a working prototype soon.

That tool would be given the GCC command line from the original or "live
patch target" kernel compilation for the source file in question, the
set of functions as determined in 1.) and a number of user provided
filter scripts to make the decisions in 3.). As a result, it would
output a self-contained, minimal subset of the original kernel sources.

With that tooling in place, live patch code size would not be a real
concern for us.

So in conclusion, what we need from GCC is the information on when we
have to live patch callers due to optimizations. If that's not possible
for a particular class of optimization, it needs to be disabled.

OTOH, we definitely want to keep the set of these disabled optimizations
as small as possible in order to limit the impact of live patching on
kernel performance. In particular, disabling any of the "cloning"
optimizations, which GCC is able to report properly, would be a
no-no IMO.

IIUC, our preferred selection of allowed IPA optimizations would be
provided by what you are referring to as "-flive-patching=inline-clone".



>> 
>>> 1. A study of Kernel live patching schemes.
>>> 
>>> Three major kernel live patching tools:  https://lwn.net/Articles/734765/
>>> 
>>> * ksplice:   http://www.ksplice.com/doc/ksplice.pdf
>>> * kpatch:    https://lwn.net/Articles/597123/
>>>            https://github.com/dynup/kpatch
>>> * kGraft:    
>>> https://pdfs.semanticscholar.org/presentation/af4c/895aa3fef0cc2b501317aaec9d91ba2d704c.pdf
>>> 
>>> In the above, ksplice and kpatch can automatically generate binary patches 
>>> as following:
>>> 
>>>   * a collection of tools which convert a source diff patch to a patch
>>> module. They work by compiling the kernel both with and without the source
>>> patch, comparing the binaries, and generating a binary patch module which 
>>> includes new binary versions of the functions to be replaced.
>>> 
>>> on the other hand, kGraft offers a way to create patches entirely by hand. 
>>> The source of the patch is a single C file, easy to review, easy to
>>> maintain. 
>>> 
>>> In addition to kGraft, there are other live patching tools that prefer
>>> creating patches by hand for the similar reason. 

Out of curiosity: which? Upstream kernel live patching?



>>> The compiler support is mainly for the above live patching tools that create 
>>> patches entirely by hand. the major purpose is:
>>> 
>>> * control patch code size and debug complexity;
>>> * keep good run time performance;
>>> 
>>> 2. the major problems of compiler in live patching:
>>> 
>>> For the live patching schemes that create patches by hand, when patching 
>>> one function, there might a list of functions that will be impacted by 
>>> this patched function due to compiler optimization/analyses (mainly IPA
>>> optimization/analyses), a complete patch will include the patched function
>>> and all impacted functions. Usually, there are two major factors to be
>>> considered in such live patching schemes:
>>> 
>>> * patch code size, one major factor is the length of the list 
>>> of impacted functions;
>>> * run time performance.
>>> 
>>> If we want to control the patch code size, to make the list of impacted 
>>> functions minimum, we have to disable corresponding compiler optimizations 
>>> as much as possible.
>> 
>> Andi already talked about it and I, too, do not understand your worry 
>> about patch code size. First, it has never been so bad here. Yes, 
>> sometimes the function closure gets bigger due to optimizations and 
>> inlining. I've considered it as nothing else than a lack of better 
>> tooling, because it is indeed something which could be improved a lot. 
>> Nicolai (CCed) works on a potential solution. It is also one of the topics 
>> at LPC miniconf in Vancouver.
>> 
>> Second, the idea to disable inlining would not fly at SUSE. I can't 
>> imagine to even propose it. The kernel heavily relies on the feature. The 
>> optimizations are a different story and some of those certainly could be 
>> disabled with no harm caused.
>> 
>> So let me ask, what is your motivation behind this? Is there a real 
>> problem you're trying to solve? It may have been mentioned somewhere and I 
>> missed it.
>
> the major functionality we want is:   to Only enable static inlining for live patching for one 
> of our internal customers.   the major purpose is to control the patch code size explosion and
> debugging complexity due to too much inlining of global functions for the specific application.
>
> therefore, I proposed the multiple level of control for -flive-patching to satisfy multiple request from 
> different users. 
>
> So far, from the feedback, I see that among the 4 levels of control,   none, only-inline-static, inline,
> and inline-clone,   “none” and “inline” are NOT needed at all.
>
> however,  -flive-patching = [only-inline-static | inline-clone] are
> necessary.

It would be interesting to learn why that internal customer is so keen
about live patch code size? I mean either their live patch creation is
somehow automated or not. In the former case, the extra .text of
inline-clone over only-inline-static would be handled by tooling anyway
and thus, wouldn't cost any additional working hours and be highly
unlikely to introduce (new) regressions to be debugged. In the latter
case, wouldn't improving the tooling also benefit the only-inline-static
case?

Thanks,

Nicolai

-- 
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)

Re: [RFC] GCC support for live-patching

[Qing Zhao]

Hi, Nicolai,

thanks a lot for your detailed explanation of the source based live patch creation procedure.
really interesting and helpful information. 

more questions and comments below:

>> 
>> One question here,  what’s the major benefit to prepare the patches manually? 
> 
> There is none. We here at SUSE prefer the source based approach (as
> opposed to binary diff) for a number of reasons and the manual live
> patch creation is simply a consequence of not having any tooling for
> this yet.
> 
> 
> For reference, source based live patch creation involves the following
> steps:
> 
> 1. Determine the initial set of to be patched functions:
>   a.) Inspect the upstream diff for the fix in question, add
>       any touched functions to the initial set.
>   b.) For each function in the initial set, check whether it has been
>       inlined/cloned/optimized and if so, add all its callers to the
>       initial set.  Repeat until the initial set has stabilized.
> 
> 2. Copy & paste the initial set over to the new live patch sources.
> 
> 3. Make it compile, i.e. recursively copy any needed cpp macro, type, or
>   functions definition and add references to data objects with static
>   storage duration.
>   The rules are:
>   a.) For data objects with static storage duration, a reference to the
>       original must always be made. (If the symbol is EXPORT()ed, then
>       fine. Otherwise, for kGraft, this involves a kallsyms lookup at
>       patch module load time, for upstream kernel live patching, this
>       has been solved with those '.klp....' relocations).
>   b.) If a called function is available as a symbol from either vmlinux
>       or some (usually the patched) module, do not copy the definition,
>       but add a reference to it, just as in a.).
>   c.) If a type, cpp macro or (usually inlined) function is provided by
>       some "public" header in <linux-tree>/include/, include that
>       rather than copying the definition.  Counterexample: Non-public
>       header outside of include/ like
>       e.g. <linux-tree>/fs/btrfs/qgroup.h.
>   d.) Otherwise copy the definition to the live patch module sources.
> 
> Rule 3b is not strictly necessary, but it helps in reducing the live
> patch code size which is a factor with _manual_ live patch creation.
> 
> For 1b.), we need help from GCC. Namely, we want to know when some
> functions has been optimized and we want it to disable any of those IPA
> optimization it (currently) isn't capable to report properly.

Yes, this this is the place that GCC can help. and it’s also the motivation for this current proposal.

> 
> Step 3.) is a bit tedious sometimes TBH and yes, w/o any tooling in
> place, patch size would be a valid point. However, I'm currently working
> on that and I'm optimistic that I'll have a working prototype soon.

So, currently, step 3 is done manually? If the initial set of patched functions is too big, this work is really
tedious and error-prone.

without a good tool for step3, controlling the initial set size of patched function is still meaningful.

> 
> That tool would be given the GCC command line from the original or "live
> patch target" kernel compilation for the source file in question, the
> set of functions as determined in 1.) and a number of user provided
> filter scripts to make the decisions in 3.). As a result, it would
> output a self-contained, minimal subset of the original kernel sources.
> 
> With that tooling in place, live patch code size would not be a real
> concern for us.

that’s good to know.

however, my question here is:

can this tool be easily adopted by other applications than linux kernel? i.e, if there is another application that tries to use GCC’s live patching
feature with manually created source patch, will your tool for step 3 be readily used by this application?  Or, this application have to develop
a similar but different tool for itself?

> 
> So in conclusion, what we need from GCC is the information on when we
> have to live patch callers due to optimizations. If that's not possible
> for a particular class of optimization, it needs to be disabled.
> 
> OTOH, we definitely want to keep the set of these disabled optimizations
> as small as possible in order to limit the impact of live patching on
> kernel performance. In particular, disabling any of the "cloning"
> optimizations, which GCC is able to report properly, would be a
> no-no IMO.
> 
> IIUC, our preferred selection of allowed IPA optimizations would be
> provided by what you are referring to as "-flive-patching=inline-clone”.

Okay. thanks for the confirmation.

are there any other IPA optimizations/analyzes in addition to the inlining, cloning, ipa-sra, etc that are critical to kernel run-time performance and currently 

have to be disabled due to report-ability concern?

>>>> 
>>>> In addition to kGraft, there are other live patching tools that prefer
>>>> creating patches by hand for the similar reason. 
> 
> Out of curiosity: which? Upstream kernel live patching?

it’s not kernel live patching. another application. 

>>>> 
>>> 
>>> So let me ask, what is your motivation behind this? Is there a real 
>>> problem you're trying to solve? It may have been mentioned somewhere and I 
>>> missed it.
>> 
>> the major functionality we want is:   to Only enable static inlining for live patching for one 
>> of our internal customers.   the major purpose is to control the patch code size explosion and
>> debugging complexity due to too much inlining of global functions for the specific application.
>> 
>> therefore, I proposed the multiple level of control for -flive-patching to satisfy multiple request from 
>> different users. 
>> 
>> So far, from the feedback, I see that among the 4 levels of control,   none, only-inline-static, inline,
>> and inline-clone,   “none” and “inline” are NOT needed at all.
>> 
>> however,  -flive-patching = [only-inline-static | inline-clone] are
>> necessary.
> 
> It would be interesting to learn why that internal customer is so keen
> about live patch code size? I mean either their live patch creation is
> somehow automated or not.

My understanding is that their patch creation is mainly by hand. as you mentioned before,  it will be very tedious and
error-prone in step 3, therefore they want to control the impacted function list as small as possible with reasonable run-time
performance. 

I am not sure how easily for them to come up with a good tool for step 3 for their application. 

> In the former case, the extra .text of
> inline-clone over only-inline-static would be handled by tooling anyway
> and thus, wouldn't cost any additional working hours and be highly
> unlikely to introduce (new) regressions to be debugged. In the latter
> case, wouldn't improving the tooling also benefit the only-inline-static
> case?

if the tool you are developing for step 3 can be easily adopted by other application than kernel,  it should helpful.

Qing
> 
> Thanks,
> 
> Nicolai
> 
> -- 
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
> HRB 21284 (AG Nürnberg)

Re: [RFC] GCC support for live-patching

[Nicolai Stange]

Hi Qing,

Qing Zhao <qing.zhao@oracle.com> writes:

> thanks a lot for your detailed explanation of the source based live patch creation procedure.
> really interesting and helpful information. 
>
> more questions and comments below:
>
>>> 
>>> One question here,  what’s the major benefit to prepare the patches manually? 
>> 
>> There is none. We here at SUSE prefer the source based approach (as
>> opposed to binary diff) for a number of reasons and the manual live
>> patch creation is simply a consequence of not having any tooling for
>> this yet.
>> 
>> 
>> For reference, source based live patch creation involves the following
>> steps:
>> 
>> 1. Determine the initial set of to be patched functions:
>>   a.) Inspect the upstream diff for the fix in question, add
>>       any touched functions to the initial set.
>>   b.) For each function in the initial set, check whether it has been
>>       inlined/cloned/optimized and if so, add all its callers to the
>>       initial set.  Repeat until the initial set has stabilized.
>> 
>> 2. Copy & paste the initial set over to the new live patch sources.
>> 
>> 3. Make it compile, i.e. recursively copy any needed cpp macro, type, or
>>   functions definition and add references to data objects with static
>>   storage duration.
>>   The rules are:
>>   a.) For data objects with static storage duration, a reference to the
>>       original must always be made. (If the symbol is EXPORT()ed, then
>>       fine. Otherwise, for kGraft, this involves a kallsyms lookup at
>>       patch module load time, for upstream kernel live patching, this
>>       has been solved with those '.klp....' relocations).
>>   b.) If a called function is available as a symbol from either vmlinux
>>       or some (usually the patched) module, do not copy the definition,
>>       but add a reference to it, just as in a.).
>>   c.) If a type, cpp macro or (usually inlined) function is provided by
>>       some "public" header in <linux-tree>/include/, include that
>>       rather than copying the definition.  Counterexample: Non-public
>>       header outside of include/ like
>>       e.g. <linux-tree>/fs/btrfs/qgroup.h.
>>   d.) Otherwise copy the definition to the live patch module sources.
>> 
>> Rule 3b is not strictly necessary, but it helps in reducing the live
>> patch code size which is a factor with _manual_ live patch creation.
>> 
>> For 1b.), we need help from GCC. Namely, we want to know when some
>> functions has been optimized and we want it to disable any of those IPA
>> optimization it (currently) isn't capable to report properly.
>
> Yes, this this is the place that GCC can help. and it’s also the motivation for this current proposal.
>
>> 
>> Step 3.) is a bit tedious sometimes TBH and yes, w/o any tooling in
>> place, patch size would be a valid point. However, I'm currently working
>> on that and I'm optimistic that I'll have a working prototype soon.
>
> So, currently, step 3 is done manually?

Currently yes.


> If the initial set of patched functions is too big, this work is
> really tedious and error-prone.

For the "tedious" part: yes it sometimes is. But we haven't seen any
problems or bugs so far. So it's reliable in practice.


>
> without a good tool for step3, controlling the initial set size of patched function is still meaningful.
>
>> 
>> That tool would be given the GCC command line from the original or "live
>> patch target" kernel compilation for the source file in question, the
>> set of functions as determined in 1.) and a number of user provided
>> filter scripts to make the decisions in 3.). As a result, it would
>> output a self-contained, minimal subset of the original kernel sources.
>> 
>> With that tooling in place, live patch code size would not be a real
>> concern for us.
>
> that’s good to know.
>
> however, my question here is:
>
> can this tool be easily adopted by other applications than linux kernel? i.e, if there is another application that tries to use GCC’s live patching
> feature with manually created source patch, will your tool for step 3 be readily used by this application?  Or, this application have to develop
> a similar but different tool for itself?

This tool's scope is the C99 language, more specifically the GCC dialect
and I'll try to keep the CLI agnostic to the application or build
environment anyway.

That said, my primary interest is the Linux kernel and I'm going to
make sure that it works there. It might not work out of the box for
random applications, but require some tweaking or even bug fixing.



>> 
>> So in conclusion, what we need from GCC is the information on when we
>> have to live patch callers due to optimizations. If that's not possible
>> for a particular class of optimization, it needs to be disabled.
>> 
>> OTOH, we definitely want to keep the set of these disabled optimizations
>> as small as possible in order to limit the impact of live patching on
>> kernel performance. In particular, disabling any of the "cloning"
>> optimizations, which GCC is able to report properly, would be a
>> no-no IMO.
>> 
>> IIUC, our preferred selection of allowed IPA optimizations would be
>> provided by what you are referring to as "-flive-patching=inline-clone”.
>
> Okay. thanks for the confirmation.
>
> are there any other IPA optimizations/analyzes in addition to the inlining, cloning, ipa-sra, etc that are critical to kernel run-time performance and currently 
>
> have to be disabled due to report-ability concern?

I really don't know that, but it gets discussed at
20181003090457.GJ57692@kam.mff.cuni.cz (this thread, email from Jan
Hubicka).


>
>>>>> 
>>>>> In addition to kGraft, there are other live patching tools that prefer
>>>>> creating patches by hand for the similar reason. 
>> 
>> Out of curiosity: which? Upstream kernel live patching?
>
> it’s not kernel live patching. another application. 

Aha.


>>>> 
>>>> So let me ask, what is your motivation behind this? Is there a real 
>>>> problem you're trying to solve? It may have been mentioned somewhere and I 
>>>> missed it.
>>> 
>>> the major functionality we want is:   to Only enable static inlining for live patching for one 
>>> of our internal customers.   the major purpose is to control the patch code size explosion and
>>> debugging complexity due to too much inlining of global functions for the specific application.
>>> 
>>> therefore, I proposed the multiple level of control for -flive-patching to satisfy multiple request from 
>>> different users. 
>>> 
>>> So far, from the feedback, I see that among the 4 levels of control,   none, only-inline-static, inline,
>>> and inline-clone,   “none” and “inline” are NOT needed at all.
>>> 
>>> however,  -flive-patching = [only-inline-static | inline-clone] are
>>> necessary.
>> 
>> It would be interesting to learn why that internal customer is so keen
>> about live patch code size? I mean either their live patch creation is
>> somehow automated or not.
>
> My understanding is that their patch creation is mainly by hand. as you mentioned before,  it will be very tedious and
> error-prone in step 3, therefore they want to control the impacted function list as small as possible with reasonable run-time
> performance.
>
> I am not sure how easily for them to come up with a good tool for step 3 for their application. 
>
>> In the former case, the extra .text of
>> inline-clone over only-inline-static would be handled by tooling anyway
>> and thus, wouldn't cost any additional working hours and be highly
>> unlikely to introduce (new) regressions to be debugged. In the latter
>> case, wouldn't improving the tooling also benefit the only-inline-static
>> case?
>
> if the tool you are developing for step 3 can be easily adopted by other application than kernel,  it should helpful.

That really depends on the application, I guess.

Thanks,

Nicolai

-- 
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)

Re: [RFC] GCC support for live-patching

[Qing Zhao]

Hi, Nicolai and Miroslav,

both of you asked for the details why our internal customer “is so keen about live patch code size” (why -flive-patching=inline-only-static is so 
important to them).  here is more details I got from them (with some update):

   Our use case is different from kGraft. Linux kernel patching involves modification of a single copy of text, in our case we can have thousands of user processes we'll have to patch. As number of candidate functions increase, so will the set of pages that will have to be modified for each process. We attempt to minimize amount of private memory consumed by each process.

   We use different infrastructure and tools from kGraft implementation. Solutions or tools that work there do not necessarily work or can be adopted by us.

   My strong preference is to not adapt online patching to global function inlining.

I hope that the above is clear. and for them to use GCC’s live patching feather, -flive-patching=inline-only-static is a must. 

thanks.

Qing


> On Oct 23, 2018, at 2:33 PM, Qing Zhao <qing.zhao@oracle.com> wrote:
>>> 
>>> however,  -flive-patching = [only-inline-static | inline-clone] are
>>> necessary.
>> 
>> It would be interesting to learn why that internal customer is so keen
>> about live patch code size? I mean either their live patch creation is
>> somehow automated or not.
> 
> My understanding is that their patch creation is mainly by hand. as you mentioned before,  it will be very tedious and
> error-prone in step 3, therefore they want to control the impacted function list as small as possible with reasonable run-time
> performance. 
> 
> I am not sure how easily for them to come up with a good tool for step 3 for their application. 



>>>>> On Oct 23, 2018, at 4:11 AM, Miroslav Benes <mbenes@suse.cz> wrote:
>>> the major functionality we want is:   to Only enable static inlining for live patching for one 
>>> of our internal customers.   the major purpose is to control the patch code size explosion and
>>> debugging complexity due to too much inlining of global functions for the specific application.
>> 
>> I hoped for more details, but ok.
> at this time, this is the details I have. I can ask more if more details are needed.

[RFC] [2nd version] GCC support for live-patching

[Qing Zhao]

Hi, 

this is the 2nd version of the proposal. the major changes are:

1.  change the option name from “-fease-live-patching” to “-flive-patching”
2.  delete two sub-options, “none”, “inline” from the list, only keep “inline-only-static” and “inline-clone”.
3.  add the importance of controlling the number of impacted function list to control memory consumption for
     live patching schemes that patch hundreds or thousands processes at the same time.
4.  re-organize the background and motivation sections based on the previous feedbacks. 

Please take a look and let me know any more comments and suggestions.

thanks.

Qing

====================================

options to help live patching in GCC (version 2)

Qing Zhao

10/31/2018
================================================

0. Terminology used in this proposal
1. The proposal
2. Two issues in live patching schemes that need compiler support 
3. Compiler support for live patching
4. Details of the proposal


0. Terminology used in this proposal:

 impacted function:

 When the body or the information extracted from the body of a function is 
used to optimize and change another function, the latter is called an impacted 
function of the former. 

 impacted function list:

 A list that includes all the impacted functions for a specific function. 

1. The proposal:

Provide two first class options in GCC to help live-patching users.

A. an option to control GCC's optimizations to provide a safe 
compilation for live-patching purpose. At the same time, provides
multiple-level control on the length of the impacted function list 
and run time performance tradeoff.

-flive-patching={inline-only-static | inline-clone}

When -flive-patching specified without any value, the default value
is "inline-clone". 

B. an option to compute the impacted function lists and dump them for
live-patching users.  

-flive-patching-list={func_name | all}{,dump_func_name}

This option guides the compiler to compute the list of impacted routines for
live patching. It only has effect when it is combined with -flive-patching.

when -flive-patching-list is specified without any value, the default value is
"all", i.e, compute the lists of impacted functions for all functions and dump 
them into stdout for the specific -flive-patching option.

Refer to Section 4 for more details of the proposal.

2. Two issues in live patching schemes that need compiler support: 

There are two major issues that need compilers' support in live patching:

   A. control the number of impacted functions;
   B. compute and report the impacted function list;

A is for the live patching scheme that patches hundreds or thousands
multiple-processes in order to control the total memory consumption. 
B is for the live patching scheme that generates patches from
source code level.  

The following is the detailed explanation of these two issues.

2.1. compute and report the impacted function list 

There are three major kernel live patching tools:  
(https://lwn.net/Articles/734765/ <https://lwn.net/Articles/734765/>)

* ksplice:   http://www.ksplice.com/doc/ksplice.pdf <http://www.ksplice.com/doc/ksplice.pdf>
* kpatch:    https://lwn.net/Articles/597123/ <https://lwn.net/Articles/597123/>
            https://github.com/dynup/kpatch <https://github.com/dynup/kpatch>
* kGraft:    
https://pdfs.semanticscholar.org/presentation/af4c/895aa3fef0cc2b501317aaec9d91ba2d704c.pdf <https://pdfs.semanticscholar.org/presentation/af4c/895aa3fef0cc2b501317aaec9d91ba2d704c.pdf>

They can be classified into two groups depending on the ways to generate
the patches:

   Group A: generate patches at binary level. the binary patches can be 
     automatically generated as following: 
     a collection of tools which convert a source diff patch to a patch
     module. They work by compiling the kernel both with and without the source
     patch, comparing the binaries, and generating a binary patch module which 
     includes new binary versions of the functions to be replaced.
     Group A includes ksplice and kpatch.

   Group B: generate patches at source code level. The source of the patch
     will be in a single C file, which is created entirely by hand. This C file
     will be compiled into the final patch module. 
     Group B includes kGraft. 

The major benefit of the live patching scheme in Group B is, the patches will be
easy to review, easy to maintain since they are C files. 

Taking kGraft as an example, Source code level patch creation involves the 
following three steps: 
(From Nicolai Stange: nstange@suse.de <mailto:nstange@suse.de>)

Step 1. Determine the initial set of to be patched functions:
 a.) Inspect the diff for the fix in question, add any touched 
     functions to the initial set.
 b.) For each function in the initial set, check whether it has been
     used by compiler analyses/optimizations to change other functions,
     an impacted function should be patched at the same time as the 
     original one. add the impacted functions to the initial set.
     Repeat until the initial set has been stabilized.

Step 2. Copy & paste the initial set over to the new live patch sources.

Step 3. Make it compile, i.e. recursively copy any needed cpp macro, type, 
 or functions definition and add references to data objects with static
 storage duration.

The above Step 1b is the first place that needs compiler support
to compute and report the list of impacted functions for each function.

2.2. Control the number of impacted functions

When the above linux kernel live patching schemes involve modification of only 
a single copy of text, there are live patching schemes for other applications
that have to patch thousands of user processes simultaneously. For such live
patching scheme, the number of patched functions has a large impact on the size
of used memory. Basically, the OS will have to make a private copy of each page 
that is modified in a process's text segment. The more functions that are patched,
the more likely it is that additional pages will have to be modified. When the
number of processes is huge, it's important to minimize amount of private memory 
consumed by each process. Therefore, it's important to control the number of 
patched functions.

There are mainly two factors to decide the number of patched functions:

   1) the initial set of patched functions;
   2) the impacted functions for each of the functions in 1). 

The above 2) is the place that needs compiler support to control the number 
of impacted functions. 

3. Compiler support for live patching.

As identified in the above section, live patching needs compiler support 
for the following two issues:

   A. control the number of impacted functions;
   B. compute and report the impacted function list;

The impacted functions are decided by the compiler optimizations that use
the body or the information extracted from the body of a function to change
other functions. Such compiler optimizations are usually IPA optimizations. 
For example, inlining a function into it's caller, cloning a function and
changing it's caller to call this new clone, or extracting a function's 
pureness/constness information to optimize it's direct or indirect callers,
etc. 

Usually, the more IPA optimizations enabled, the larger the number of
impacted functions for each function. In order to control the number of 
impacted functions, we should provide control to partially enable IPA
optimizations on different levels. 

Only for enabled IPA optimization, we compute and report the impacted function
list for each function. all the other IPA optimizations should be disabled.

currently, we have requests for the following two levels of control:

  level 1:  inline-only-static
  only enable inlining of static functions, disable all other IPA optimizations.
  This is mainly for the live patching user who has to patch thousands of 
  processes simutaniously to control the memory consumption.

  level 2:  inline-clone
  Only enable inlining and all optimizations that internally create clone,
  for example, cloning, ipa-sra, partial inlining, etc.; disable all
  other IPA optimizations/analyses. 

  This is manly for the live patching users who create patches on source code
  level.

We can definitely extend to other levels later if needed. If run-time performance
is critical, more IPA optimizations need to be enabled; On the other hand, 
if memory consumption is more critical, less IPA optimizations need to be enabled.

4. Details of the proposal:

What should GCC provide to live-patching users? 

A. an option to control GCC's optimizations to provide a safe 
compilation for live-patching purpose. At the same time, provides
multiple-level control on the length of the impacted function list 
and run time performance tradeoff.

-flive-patching={only-inline-static|inline-clone}

-flive-patching=only-inline-static

  Only enable inlining of static functions, disable all other IPA 
optimizations/analyses. As a result, when patching a static routine,
all its callers need to be patches as well.

-flive-patching=inline-clone

  Only enable inlining and all optimizations that internally create clone,
for example, cloning, ipa-sra, partial inlining, etc.; disable all 
other IPA optimizations/analyses.
  As a result, when patching a routine, all its callers and its clones'
callers need to be patched as well. 

When -flive-patching specified without any value, the default value
is "inline-clone". 

B. an option to compute the impacted function lists and dump them for
live-patching users.  

-flive-patching-list={func_name|all}{,dump_func_name}

This option guides the compiler to compute the list of impacted routines for
live patching. It only has effect when it is combined with -flive-patching.

-flive-patching-list=func_name

compute the list of impacted routines for the routine "func_name" and dump it
into stdout.

-flive-patching-list=all

compute the list of impacted routines for all routines and dump them 
into stdout.

-flive-patching-list=func_name,dump_func_name

compute the list of impacted routines for the routine "func_name" and dump it
into the file "dump_func_name".

-flive-patching-list=all,dump_func_name

compute the list of impacted routines for all routines and dump them 
into the file "dump_func_name".

when -flive-patching-list is specified without any value, the default value is
"all", i.e, compute the lists of impacted routines for all routinesand dump 
them into stdout.

Re: [RFC] GCC support for live-patching

[Qing Zhao]

Hi, 
(resend to CCing more people who provided feedbacks in previous discuss, the alias “live-patching@vger.kernel.org <mailto:live-patching@vger.kernel.org>” was unreachable)

this is the 2nd version of the proposal. the major changes are:

1.  change the option name from “-fease-live-patching” to “-flive-patching”
2.  delete two sub-options, “none”, “inline” from the list, only keep “inline-only-static” and “inline-clone”.
3.  add the importance of controlling the number of impacted function list to control memory consumption for
    live patching schemes that patch hundreds or thousands processes at the same time.
4.  re-organize the background and motivation sections based on the previous feedbacks. 

Please take a look and let me know any more comments and suggestions.

thanks.

Qing

====================================

options to help live patching in GCC (version 2)

Qing Zhao

10/31/2018
================================================

0. Terminology used in this proposal
1. The proposal
2. Two issues in live patching schemes that need compiler support 
3. Compiler support for live patching
4. Details of the proposal


0. Terminology used in this proposal:

impacted function:

When the body or the information extracted from the body of a function is 
used to optimize and change another function, the latter is called an impacted 
function of the former. 

impacted function list:

A list that includes all the impacted functions for a specific function. 

1. The proposal:

Provide two first class options in GCC to help live-patching users.

A. an option to control GCC's optimizations to provide a safe 
compilation for live-patching purpose. At the same time, provides
multiple-level control on the length of the impacted function list 
and run time performance tradeoff.

-flive-patching={inline-only-static | inline-clone}

When -flive-patching specified without any value, the default value
is "inline-clone". 

B. an option to compute the impacted function lists and dump them for
live-patching users.  

-flive-patching-list={func_name | all}{,dump_func_name}

This option guides the compiler to compute the list of impacted routines for
live patching. It only has effect when it is combined with -flive-patching.

when -flive-patching-list is specified without any value, the default value is
"all", i.e, compute the lists of impacted functions for all functions and dump 
them into stdout for the specific -flive-patching option.

Refer to Section 4 for more details of the proposal.

2. Two issues in live patching schemes that need compiler support: 

There are two major issues that need compilers' support in live patching:

  A. control the number of impacted functions;
  B. compute and report the impacted function list;

A is for the live patching scheme that patches hundreds or thousands
multiple-processes in order to control the total memory consumption. 
B is for the live patching scheme that generates patches from
source code level.  

The following is the detailed explanation of these two issues.

2.1. compute and report the impacted function list 

There are three major kernel live patching tools:  
(https://lwn.net/Articles/734765/ <https://lwn.net/Articles/734765/> <https://lwn.net/Articles/734765/ <https://lwn.net/Articles/734765/>>)

* ksplice:   http://www.ksplice.com/doc/ksplice.pdf <http://www.ksplice.com/doc/ksplice.pdf> <http://www.ksplice.com/doc/ksplice.pdf <http://www.ksplice.com/doc/ksplice.pdf>>
* kpatch:    https://lwn.net/Articles/597123/ <https://lwn.net/Articles/597123/> <https://lwn.net/Articles/597123/ <https://lwn.net/Articles/597123/>>
           https://github.com/dynup/kpatch <https://github.com/dynup/kpatch> <https://github.com/dynup/kpatch <https://github.com/dynup/kpatch>>
* kGraft:    
https://pdfs.semanticscholar.org/presentation/af4c/895aa3fef0cc2b501317aaec9d91ba2d704c.pdf <https://pdfs.semanticscholar.org/presentation/af4c/895aa3fef0cc2b501317aaec9d91ba2d704c.pdf> <https://pdfs.semanticscholar.org/presentation/af4c/895aa3fef0cc2b501317aaec9d91ba2d704c.pdf <https://pdfs.semanticscholar.org/presentation/af4c/895aa3fef0cc2b501317aaec9d91ba2d704c.pdf>>

They can be classified into two groups depending on the ways to generate
the patches:

  Group A: generate patches at binary level. the binary patches can be 
    automatically generated as following: 
    a collection of tools which convert a source diff patch to a patch
    module. They work by compiling the kernel both with and without the source
    patch, comparing the binaries, and generating a binary patch module which 
    includes new binary versions of the functions to be replaced.
    Group A includes ksplice and kpatch.

  Group B: generate patches at source code level. The source of the patch
    will be in a single C file, which is created entirely by hand. This C file
    will be compiled into the final patch module. 
    Group B includes kGraft. 

The major benefit of the live patching scheme in Group B is, the patches will be
easy to review, easy to maintain since they are C files. 

Taking kGraft as an example, Source code level patch creation involves the 
following three steps: 
(From Nicolai Stange: nstange@suse.de <mailto:nstange@suse.de> <mailto:nstange@suse.de <mailto:nstange@suse.de>>)

Step 1. Determine the initial set of to be patched functions:
a.) Inspect the diff for the fix in question, add any touched 
    functions to the initial set.
b.) For each function in the initial set, check whether it has been
    used by compiler analyses/optimizations to change other functions,
    an impacted function should be patched at the same time as the 
    original one. add the impacted functions to the initial set.
    Repeat until the initial set has been stabilized.

Step 2. Copy & paste the initial set over to the new live patch sources.

Step 3. Make it compile, i.e. recursively copy any needed cpp macro, type, 
or functions definition and add references to data objects with static
storage duration.

The above Step 1b is the first place that needs compiler support
to compute and report the list of impacted functions for each function.

2.2. Control the number of impacted functions

When the above linux kernel live patching schemes involve modification of only 
a single copy of text, there are live patching schemes for other applications
that have to patch thousands of user processes simultaneously. For such live
patching scheme, the number of patched functions has a large impact on the size
of used memory. Basically, the OS will have to make a private copy of each page 
that is modified in a process's text segment. The more functions that are patched,
the more likely it is that additional pages will have to be modified. When the
number of processes is huge, it's important to minimize amount of private memory 
consumed by each process. Therefore, it's important to control the number of 
patched functions.

There are mainly two factors to decide the number of patched functions:

  1) the initial set of patched functions;
  2) the impacted functions for each of the functions in 1). 

The above 2) is the place that needs compiler support to control the number 
of impacted functions. 

3. Compiler support for live patching.

As identified in the above section, live patching needs compiler support 
for the following two issues:

  A. control the number of impacted functions;
  B. compute and report the impacted function list;

The impacted functions are decided by the compiler optimizations that use
the body or the information extracted from the body of a function to change
other functions. Such compiler optimizations are usually IPA optimizations. 
For example, inlining a function into it's caller, cloning a function and
changing it's caller to call this new clone, or extracting a function's 
pureness/constness information to optimize it's direct or indirect callers,
etc. 

Usually, the more IPA optimizations enabled, the larger the number of
impacted functions for each function. In order to control the number of 
impacted functions, we should provide control to partially enable IPA
optimizations on different levels. 

Only for enabled IPA optimization, we compute and report the impacted function
list for each function. all the other IPA optimizations should be disabled.

currently, we have requests for the following two levels of control:

 level 1:  inline-only-static
 only enable inlining of static functions, disable all other IPA optimizations.
 This is mainly for the live patching user who has to patch thousands of 
 processes simutaniously to control the memory consumption.

 level 2:  inline-clone
 Only enable inlining and all optimizations that internally create clone,
 for example, cloning, ipa-sra, partial inlining, etc.; disable all
 other IPA optimizations/analyses. 

 This is manly for the live patching users who create patches on source code
 level.

We can definitely extend to other levels later if needed. If run-time performance
is critical, more IPA optimizations need to be enabled; On the other hand, 
if memory consumption is more critical, less IPA optimizations need to be enabled.

4. Details of the proposal:

What should GCC provide to live-patching users? 

A. an option to control GCC's optimizations to provide a safe 
compilation for live-patching purpose. At the same time, provides
multiple-level control on the length of the impacted function list 
and run time performance tradeoff.

-flive-patching={only-inline-static|inline-clone}

-flive-patching=only-inline-static

 Only enable inlining of static functions, disable all other IPA 
optimizations/analyses. As a result, when patching a static routine,
all its callers need to be patches as well.

-flive-patching=inline-clone

 Only enable inlining and all optimizations that internally create clone,
for example, cloning, ipa-sra, partial inlining, etc.; disable all 
other IPA optimizations/analyses.
 As a result, when patching a routine, all its callers and its clones'
callers need to be patched as well. 

When -flive-patching specified without any value, the default value
is "inline-clone". 

B. an option to compute the impacted function lists and dump them for
live-patching users.  

-flive-patching-list={func_name|all}{,dump_func_name}

This option guides the compiler to compute the list of impacted routines for
live patching. It only has effect when it is combined with -flive-patching.

-flive-patching-list=func_name

compute the list of impacted routines for the routine "func_name" and dump it
into stdout.

-flive-patching-list=all

compute the list of impacted routines for all routines and dump them 
into stdout.

-flive-patching-list=func_name,dump_func_name

compute the list of impacted routines for the routine "func_name" and dump it
into the file "dump_func_name".

-flive-patching-list=all,dump_func_name

compute the list of impacted routines for all routines and dump them 
into the file "dump_func_name".

when -flive-patching-list is specified without any value, the default value is
"all", i.e, compute the lists of impacted routines for all routinesand dump 
them into stdout.

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

[Jan Hubicka]

> 
> 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.

 We have transformations that are modeled as clonning, which are
  - inlining  (can't be disabled completely because of always inline, but -fno-inline
    does most of stuff)
  - cloning (disabled via -fno-ipa-cp)
  - ipa-sra (-fno-ipa-sra)
  - splitting (-fno-partial-inlining)
 These should play well with Martin's tracking code

 We propagate info about side effects of function:
  - function attribute discovery (pure, const, nothrow, malloc)
    Some of this can be disabled by -fno-ipa-pure-const, but not all
    of it.  Nothrow does not have flag but it is obviously not a concern
    for C++
  - 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)
  - inter-procedural register allocation (-fno-ipa-ra)

 We perform discovery of functions/variables with no address taken and
 optimizations that are not valid otherwise such as duplicating them
 or doing skipping them for alias analysis (no flag to disable)

 Identical code folding merges function bodies that are semanticaly equivalent
 and thus one can't patch one without patching another, -fno-ipa-icf

 Unreachable code/variable removal may be concern too (no flag to disable)

 Write only global variable discovery (no flag to dosable)

 Visibility changes with -flto and/or -fwhole-program

 We also have profile propagation (discovery of cuntions used only in cold regions,
 but that I guess is only performance issue not correctness)
 No flag to disable

Honza

> 
> Martin
> 
> >
> >thanks.
> >
> >Qing
> >
> 

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

[Martin Liška]

On 10/3/18 11: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.

Heh! Thanks for the analysis.

> 
>  We have transformations that are modeled as clonning, which are
>   - inlining  (can't be disabled completely because of always inline, but -fno-inline
>     does most of stuff)
>   - cloning (disabled via -fno-ipa-cp)
>   - ipa-sra (-fno-ipa-sra)
>   - splitting (-fno-partial-inlining)
>  These should play well with Martin's tracking code

I hope so!

> 
>  We propagate info about side effects of function:
>   - function attribute discovery (pure, const, nothrow, malloc)
>     Some of this can be disabled by -fno-ipa-pure-const, but not all
>     of it.

Would it be possible to add option for the remaining ones?

Nothrow does not have flag but it is obviously not a concern
>     for C++

s/C++/C?

>   - 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 where
the optimization happen?

>   - inter-procedural register allocation (-fno-ipa-ra)
> 
>  We perform discovery of functions/variables with no address taken and
>  optimizations that are not valid otherwise such as duplicating them
>  or doing skipping them for alias analysis (no flag to disable)

Can you be please more verbose here? What optimizations do you mean?

> 
>  Identical code folding merges function bodies that are semanticaly equivalent
>  and thus one can't patch one without patching another, -fno-ipa-icf

Agree, I recommend disabling that.

> 
>  Unreachable code/variable removal may be concern too (no flag to disable)

For functions that should be fine and handled by my script.
For variables can be problem when a variable becomes alive But that
should be extremely rare for live-patching.

> 
>  Write only global variable discovery (no flag to dosable)

Similarly.

> 
>  Visibility changes with -flto and/or -fwhole-program
> 
>  We also have profile propagation (discovery of cuntions used only in cold regions,
>  but that I guess is only performance issue not correctness)
>  No flag to disable

Hope these 2 does not happen for current Linux kernel.

Martin

> 
> Honza
> 
>>
>> Martin
>>
>>>
>>> thanks.
>>>
>>> Qing
>>>
>>

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

[Martin Liška]

@honza: PING

On 10/3/18 12:53 PM, Martin Liška wrote:
> On 10/3/18 11: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.
> 
> Heh! Thanks for the analysis.
> 
>>
>>  We have transformations that are modeled as clonning, which are
>>   - inlining  (can't be disabled completely because of always inline, but -fno-inline
>>     does most of stuff)
>>   - cloning (disabled via -fno-ipa-cp)
>>   - ipa-sra (-fno-ipa-sra)
>>   - splitting (-fno-partial-inlining)
>>  These should play well with Martin's tracking code
> 
> I hope so!
> 
>>
>>  We propagate info about side effects of function:
>>   - function attribute discovery (pure, const, nothrow, malloc)
>>     Some of this can be disabled by -fno-ipa-pure-const, but not all
>>     of it.
> 
> Would it be possible to add option for the remaining ones?
> 
> Nothrow does not have flag but it is obviously not a concern
>>     for C++
> 
> s/C++/C?
> 
>>   - 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 where
> the optimization happen?
> 
>>   - inter-procedural register allocation (-fno-ipa-ra)
>>
>>  We perform discovery of functions/variables with no address taken and
>>  optimizations that are not valid otherwise such as duplicating them
>>  or doing skipping them for alias analysis (no flag to disable)
> 
> Can you be please more verbose here? What optimizations do you mean?
> 
>>
>>  Identical code folding merges function bodies that are semanticaly equivalent
>>  and thus one can't patch one without patching another, -fno-ipa-icf
> 
> Agree, I recommend disabling that.
> 
>>
>>  Unreachable code/variable removal may be concern too (no flag to disable)
> 
> For functions that should be fine and handled by my script.
> For variables can be problem when a variable becomes alive But that
> should be extremely rare for live-patching.
> 
>>
>>  Write only global variable discovery (no flag to dosable)
> 
> Similarly.
> 
>>
>>  Visibility changes with -flto and/or -fwhole-program
>>
>>  We also have profile propagation (discovery of cuntions used only in cold regions,
>>  but that I guess is only performance issue not correctness)
>>  No flag to disable
> 
> Hope these 2 does not happen for current Linux kernel.
> 
> Martin
> 
>>
>> Honza
>>
>>>
>>> Martin
>>>
>>>>
>>>> thanks.
>>>>
>>>> Qing
>>>>
>>>
> 

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

[Qing Zhao]

>>> 
>>>>  - 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 where
>>> the optimization happen?
> 
> In expand_call
> 
>  /* Figure out the amount to which the stack should be aligned.  */
>  preferred_stack_boundary = PREFERRED_STACK_BOUNDARY;
>  if (fndecl)
>    {
>      struct cgraph_rtl_info *i = cgraph_node::rtl_info (fndecl);
>      /* Without automatic stack alignment, we can't increase preferred
>         stack boundary.  With automatic stack alignment, it is
>         unnecessary since unless we can guarantee that all callers will
>         align the outgoing stack properly, callee has to align its
>         stack anyway.  */
>      if (i
>          && i->preferred_incoming_stack_boundary
>          && i->preferred_incoming_stack_boundary < preferred_stack_boundary)
>        preferred_stack_boundary = i->preferred_incoming_stack_boundary;
>    }
> 

As I checked, in the above, i->preferred_incoming_stack_boundary is set to non-zero
when "decl_binds_to_current_def_p ()” is TRUE as the following: (in rest_of_clean_state()
of final.c)

  /* We can reduce stack alignment on call site only when we are sure that
     the function body just produced will be actually used in the final
     executable.  */
  if (decl_binds_to_current_def_p (current_function_decl))
    {
      unsigned int pref = crtl->preferred_stack_boundary;
      if (crtl->stack_alignment_needed > crtl->preferred_stack_boundary)
        pref = crtl->stack_alignment_needed;
      cgraph_node::rtl_info (current_function_decl)
        ->preferred_incoming_stack_boundary = pref;
    }

It looks like that “decl_binds_to_current_def_p()”  will be FALSE when the routine
is live-patched, right? 
So, should we disable all the places that guided by “decl_binds_to_current_def_p()”? 

thanks.

Qing

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

[Martin Liška]

[-- Attachment #1: Type: text/plain, Size: 4570 bytes --]

On 11/5/18 10:51 AM, Jan Hubicka wrote:
>> @honza: PING
>>
>> On 10/3/18 12:53 PM, Martin Liška wrote:
>>> On 10/3/18 11: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.
>>>
>>> Heh! Thanks for the analysis.
>>>
>>>>
>>>>  We have transformations that are modeled as clonning, which are
>>>>   - inlining  (can't be disabled completely because of always inline, but -fno-inline
>>>>     does most of stuff)
>>>>   - cloning (disabled via -fno-ipa-cp)
>>>>   - ipa-sra (-fno-ipa-sra)
>>>>   - splitting (-fno-partial-inlining)
>>>>  These should play well with Martin's tracking code
>>>
>>> I hope so!
>>>
>>>>
>>>>  We propagate info about side effects of function:
>>>>   - function attribute discovery (pure, const, nothrow, malloc)
>>>>     Some of this can be disabled by -fno-ipa-pure-const, but not all
>>>>     of it.
>>>
>>> Would it be possible to add option for the remaining ones?
> 
> Sure, I can prepare patch unless you beat me :)

Are you sure there's a call to 'analyze_function' where the analysis is done
when one sets -fno-ipa-pure-const?

>>>
>>> Nothrow does not have flag but it is obviously not a concern
>>>>     for C++
>>>
>>> s/C++/C?
> 
> Yep for C
>>>
>>>>   - 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 where
>>> the optimization happen?
> 
> In expand_call
> 
>   /* Figure out the amount to which the stack should be aligned.  */
>   preferred_stack_boundary = PREFERRED_STACK_BOUNDARY;
>   if (fndecl)
>     {
>       struct cgraph_rtl_info *i = cgraph_node::rtl_info (fndecl);
>       /* Without automatic stack alignment, we can't increase preferred
>          stack boundary.  With automatic stack alignment, it is
>          unnecessary since unless we can guarantee that all callers will
>          align the outgoing stack properly, callee has to align its
>          stack anyway.  */
>       if (i
>           && i->preferred_incoming_stack_boundary
>           && i->preferred_incoming_stack_boundary < preferred_stack_boundary)
>         preferred_stack_boundary = i->preferred_incoming_stack_boundary;
>     }

I'm attaching patch candidate for that.

> 
>>>
>>>>   - inter-procedural register allocation (-fno-ipa-ra)
>>>>
>>>>  We perform discovery of functions/variables with no address taken and
>>>>  optimizations that are not valid otherwise such as duplicating them
>>>>  or doing skipping them for alias analysis (no flag to disable)
>>>
>>> Can you be please more verbose here? What optimizations do you mean?
> 
> See ipa_discover_readonly_nonaddressable_vars. If addressable bit is
> cleared we start analyzing uses of the variable via ipa_reference or so.
> If writeonly bit is set, we start removing writes to the variable and if
> readonly bit is set we skip any analysis about whether vairable changed.

Likewise for this.

>>>
>>>>
>>>>  Identical code folding merges function bodies that are semanticaly equivalent
>>>>  and thus one can't patch one without patching another, -fno-ipa-icf
>>>
>>> Agree, I recommend disabling that.
>>>
>>>>
>>>>  Unreachable code/variable removal may be concern too (no flag to disable)
>>>
>>> For functions that should be fine and handled by my script.
>>> For variables can be problem when a variable becomes alive But that
>>> should be extremely rare for live-patching.
>>>
>>>>
>>>>  Write only global variable discovery (no flag to dosable)
>>>
>>> Similarly.
>>>
>>>>
>>>>  Visibility changes with -flto and/or -fwhole-program
>>>>
>>>>  We also have profile propagation (discovery of cuntions used only in cold regions,
>>>>  but that I guess is only performance issue not correctness)
>>>>  No flag to disable
>>>
>>> Hope these 2 does not happen for current Linux kernel.
> 
> 2 will happen in kernel.  We will try to propagate cold code
> inter-procedurally based on what we think will be undefined effect at
> runtime.  Still i guess it is not big deal as it only affects 
> size optimization.

Then let's ignore it.

Thoughts about the patches?
Martin

> 
> Honza
>>>
>>> Martin
>>>
>>>>
>>>> Honza
>>>>
>>>>>
>>>>> Martin
>>>>>
>>>>>>
>>>>>> thanks.
>>>>>>
>>>>>> Qing
>>>>>>
>>>>>
>>>
>>


[-- Attachment #2: 0002-Come-up-with-the-flag-fipa-stack-alignment.patch --]
[-- Type: text/x-patch, Size: 3666 bytes --]

From ee912514f61ec2c4d126cf6d43b69d01a08886c8 Mon Sep 17 00:00:00 2001
From: marxin <mliska@suse.cz>
Date: Wed, 7 Nov 2018 13:47:40 +0100
Subject: [PATCH 2/2] Come up with the flag -fipa-stack-alignment.

gcc/ChangeLog:

2018-11-07  Martin Liska  <mliska@suse.cz>

	* common.opt: Add -fipa-stack-alignment flag.
	* doc/invoke.texi: Document it.
	* final.c (rest_of_clean_state): Guard stack
	shrinking with flag.

gcc/testsuite/ChangeLog:

2018-11-07  Martin Liska  <mliska@suse.cz>

	* gcc.target/i386/ipa-stack-alignment.c: New test.
---
 gcc/common.opt                                      |  4 ++++
 gcc/doc/invoke.texi                                 |  7 ++++++-
 gcc/final.c                                         |  3 ++-
 gcc/testsuite/gcc.target/i386/ipa-stack-alignment.c | 13 +++++++++++++
 4 files changed, 25 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/i386/ipa-stack-alignment.c

diff --git a/gcc/common.opt b/gcc/common.opt
index 6a64b0e27d5..6ee48fbcfc4 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1724,6 +1724,10 @@ fipa-reference-addressable
 Common Report Var(flag_ipa_reference_addressable) Init(0) Optimization
 Discover read-only and write-only addressable variables.
 
+fipa-stack-alignment
+Common Report Var(flag_ipa_stack_alignment) Init(1) Optimization
+Reduce stack alignment on call sites if possible.
+
 fipa-matrix-reorg
 Common Ignore
 Does nothing. Preserved for backward compatibility.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 82c6fa913e8..2332e643993 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -413,7 +413,7 @@ Objective-C and Objective-C++ Dialects}.
 -finline-small-functions  -fipa-cp  -fipa-cp-clone @gol
 -fipa-bit-cp -fipa-vrp @gol
 -fipa-pta  -fipa-profile  -fipa-pure-const  -fipa-reference  -fipa-reference-addressable @gol
--fipa-icf  -fira-algorithm=@var{algorithm} @gol
+-fipa-stack-alignment  -fipa-icf  -fira-algorithm=@var{algorithm} @gol
 -fira-region=@var{region}  -fira-hoist-pressure @gol
 -fira-loop-pressure  -fno-ira-share-save-slots @gol
 -fno-ira-share-spill-slots @gol
@@ -8901,6 +8901,11 @@ Enabled by default at @option{-O} and higher.
 Discover read-only and write-only addressable variables.
 Enabled by default at @option{-O} and higher.
 
+@item -fipa-stack-alignment
+@opindex fipa-stack-alignment
+Reduce stack alignment on call sites if possible.
+Enabled by default.
+
 @item -fipa-pta
 @opindex fipa-pta
 Perform interprocedural pointer analysis and interprocedural modification
diff --git a/gcc/final.c b/gcc/final.c
index 6e61f1e17a8..0c1ac625f37 100644
--- a/gcc/final.c
+++ b/gcc/final.c
@@ -4890,7 +4890,8 @@ rest_of_clean_state (void)
   /* We can reduce stack alignment on call site only when we are sure that
      the function body just produced will be actually used in the final
      executable.  */
-  if (decl_binds_to_current_def_p (current_function_decl))
+  if (flag_ipa_stack_alignment
+      && decl_binds_to_current_def_p (current_function_decl))
     {
       unsigned int pref = crtl->preferred_stack_boundary;
       if (crtl->stack_alignment_needed > crtl->preferred_stack_boundary)
diff --git a/gcc/testsuite/gcc.target/i386/ipa-stack-alignment.c b/gcc/testsuite/gcc.target/i386/ipa-stack-alignment.c
new file mode 100644
index 00000000000..1176b59aa5f
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/ipa-stack-alignment.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-fno-ipa-stack-alignment -O" } */
+
+typedef struct {
+  long a;
+  long b[];
+} c;
+
+c *d;
+void e() { d->b[0] = 5; }
+void f() { e(); }
+
+/* { dg-final { scan-assembler "sub.*%.sp" } } */
-- 
2.19.1


[-- Attachment #3: 0001-Come-up-with-fipa-reference-addressable-flag.patch --]
[-- Type: text/x-patch, Size: 7406 bytes --]

From 8691490a142228021ed65313a72d176d06966829 Mon Sep 17 00:00:00 2001
From: marxin <mliska@suse.cz>
Date: Wed, 7 Nov 2018 13:31:41 +0100
Subject: [PATCH 1/2] Come up with -fipa-reference-addressable flag.

gcc/ChangeLog:

2018-11-07  Martin Liska  <mliska@suse.cz>

	* cgraph.h (ipa_discover_readonly_nonaddressable_vars): Rename
	to ...
	(ipa_discover_nonaddressable_vars): ... this.
	* common.opt: Come up with new flag -fipa-reference-addressable.
	* doc/invoke.texi: Document it.
	* ipa-reference.c (propagate): Call the renamed fn.
	* ipa-visibility.c (whole_program_function_and_variable_visibility):
	Likewise.
	* ipa.c (ipa_discover_readonly_nonaddressable_vars): Renamed to
	...
	(ipa_discover_nonaddressable_vars): ... this.  Discove
	non-addressable variables only with the newly added flag.
	* opts.c: Enable the newly added flag with -O1 and higher
	optimization level.

gcc/testsuite/ChangeLog:

2018-11-07  Martin Liska  <mliska@suse.cz>

	* gcc.dg/tree-ssa/writeonly-2.c: New test.
---
 gcc/cgraph.h                                |  2 +-
 gcc/common.opt                              |  6 +++++-
 gcc/doc/invoke.texi                         | 10 ++++++++--
 gcc/ipa-reference.c                         |  2 +-
 gcc/ipa-visibility.c                        |  2 +-
 gcc/ipa.c                                   | 11 +++++++----
 gcc/opts.c                                  |  1 +
 gcc/testsuite/gcc.dg/tree-ssa/writeonly-2.c | 20 ++++++++++++++++++++
 8 files changed, 44 insertions(+), 10 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/writeonly-2.c

diff --git a/gcc/cgraph.h b/gcc/cgraph.h
index c13d79850fa..bf65d426cda 100644
--- a/gcc/cgraph.h
+++ b/gcc/cgraph.h
@@ -2403,7 +2403,7 @@ void record_references_in_initializer (tree, bool);
 
 /* In ipa.c  */
 void cgraph_build_static_cdtor (char which, tree body, int priority);
-bool ipa_discover_readonly_nonaddressable_vars (void);
+bool ipa_discover_nonaddressable_vars (void);
 
 /* In varpool.c  */
 tree ctor_for_folding (tree);
diff --git a/gcc/common.opt b/gcc/common.opt
index 2971dc21b1f..6a64b0e27d5 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1718,7 +1718,11 @@ Perform Identical Code Folding for variables.
 
 fipa-reference
 Common Report Var(flag_ipa_reference) Init(0) Optimization
-Discover readonly and non addressable static variables.
+Discover read-only and non addressable static variables.
+
+fipa-reference-addressable
+Common Report Var(flag_ipa_reference_addressable) Init(0) Optimization
+Discover read-only and write-only addressable variables.
 
 fipa-matrix-reorg
 Common Ignore
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index ae260c6ac6d..82c6fa913e8 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -412,8 +412,8 @@ Objective-C and Objective-C++ Dialects}.
 -finline-functions  -finline-functions-called-once  -finline-limit=@var{n} @gol
 -finline-small-functions  -fipa-cp  -fipa-cp-clone @gol
 -fipa-bit-cp -fipa-vrp @gol
--fipa-pta  -fipa-profile  -fipa-pure-const  -fipa-reference  -fipa-icf @gol
--fira-algorithm=@var{algorithm} @gol
+-fipa-pta  -fipa-profile  -fipa-pure-const  -fipa-reference  -fipa-reference-addressable @gol
+-fipa-icf  -fira-algorithm=@var{algorithm} @gol
 -fira-region=@var{region}  -fira-hoist-pressure @gol
 -fira-loop-pressure  -fno-ira-share-save-slots @gol
 -fno-ira-share-spill-slots @gol
@@ -7866,6 +7866,7 @@ compilation time.
 -fipa-pure-const @gol
 -fipa-profile @gol
 -fipa-reference @gol
+-fipa-reference-addressable @gol
 -fmerge-constants @gol
 -fmove-loop-invariants @gol
 -fomit-frame-pointer @gol
@@ -8895,6 +8896,11 @@ Discover which static variables do not escape the
 compilation unit.
 Enabled by default at @option{-O} and higher.
 
+@item -fipa-reference-addressable
+@opindex fipa-reference-addressable
+Discover read-only and write-only addressable variables.
+Enabled by default at @option{-O} and higher.
+
 @item -fipa-pta
 @opindex fipa-pta
 Perform interprocedural pointer analysis and interprocedural modification
diff --git a/gcc/ipa-reference.c b/gcc/ipa-reference.c
index 43bbdae5d66..2cdce3cbfa6 100644
--- a/gcc/ipa-reference.c
+++ b/gcc/ipa-reference.c
@@ -705,7 +705,7 @@ propagate (void)
   if (dump_file)
     cgraph_node::dump_cgraph (dump_file);
 
-  remove_p = ipa_discover_readonly_nonaddressable_vars ();
+  remove_p = ipa_discover_nonaddressable_vars ();
   generate_summary ();
 
   /* Propagate the local information through the call graph to produce
diff --git a/gcc/ipa-visibility.c b/gcc/ipa-visibility.c
index 000207fa31b..1da594111f8 100644
--- a/gcc/ipa-visibility.c
+++ b/gcc/ipa-visibility.c
@@ -911,7 +911,7 @@ whole_program_function_and_variable_visibility (void)
 {
   function_and_variable_visibility (flag_whole_program);
   if (optimize || in_lto_p)
-    ipa_discover_readonly_nonaddressable_vars ();
+    ipa_discover_nonaddressable_vars ();
   return 0;
 }
 
diff --git a/gcc/ipa.c b/gcc/ipa.c
index 3b6b5e5c8d4..eb53e7dcd06 100644
--- a/gcc/ipa.c
+++ b/gcc/ipa.c
@@ -752,10 +752,10 @@ clear_addressable_bit (varpool_node *vnode, void *data ATTRIBUTE_UNUSED)
   return false;
 }
 
-/* Discover variables that have no longer address taken or that are read only
-   and update their flags.
+/* Discover variables that have no longer address taken, are read-only or
+   write-only and update their flags.
 
-   Return true when unreachable symbol removan should be done.
+   Return true when unreachable symbol removal should be done.
 
    FIXME: This can not be done in between gimplify and omp_expand since
    readonly flag plays role on what is shared and what is not.  Currently we do
@@ -764,8 +764,11 @@ clear_addressable_bit (varpool_node *vnode, void *data ATTRIBUTE_UNUSED)
    make sense to do it before early optimizations.  */
 
 bool
-ipa_discover_readonly_nonaddressable_vars (void)
+ipa_discover_nonaddressable_vars (void)
 {
+  if (!flag_ipa_reference_addressable)
+    return false;
+
   bool remove_p = false;
   varpool_node *vnode;
   if (dump_file)
diff --git a/gcc/opts.c b/gcc/opts.c
index 34c283dd765..9b9018c6c48 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -451,6 +451,7 @@ static const struct default_options default_options_table[] =
     { OPT_LEVELS_1_PLUS_NOT_DEBUG, OPT_fif_conversion2, NULL, 1 },
     { OPT_LEVELS_1_PLUS, OPT_fipa_pure_const, NULL, 1 },
     { OPT_LEVELS_1_PLUS, OPT_fipa_reference, NULL, 1 },
+    { OPT_LEVELS_1_PLUS, OPT_fipa_reference_addressable, NULL, 1 },
     { OPT_LEVELS_1_PLUS, OPT_fipa_profile, NULL, 1 },
     { OPT_LEVELS_1_PLUS, OPT_fmerge_constants, NULL, 1 },
     { OPT_LEVELS_1_PLUS, OPT_freorder_blocks, NULL, 1 },
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/writeonly-2.c b/gcc/testsuite/gcc.dg/tree-ssa/writeonly-2.c
new file mode 100644
index 00000000000..2272d15b171
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/writeonly-2.c
@@ -0,0 +1,20 @@
+/* { dg-do compile } */
+/* { dg-options "-O1 -fdump-tree-optimized -fno-ipa-reference-addressable" } */
+static struct a {int magic1,b;} a;
+volatile int magic2;
+static struct b {int a,b,c,d,e,f;} magic3;
+
+struct b foo();
+
+void
+t()
+{
+ a.magic1 = 1;
+ magic2 = 1;
+ magic3 = foo();
+}
+/* { dg-final { scan-tree-dump "magic1" "optimized"} } */
+/* { dg-final { scan-tree-dump "magic3" "optimized"} } */
+/* { dg-final { scan-tree-dump "magic2" "optimized"} } */
+/* { dg-final { scan-tree-dump "foo" "optimized"} } */
+ 
-- 
2.19.1

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

[Jan Hubicka]

> On 11/5/18 10:51 AM, Jan Hubicka wrote:
> >> @honza: PING
> >>
> >> On 10/3/18 12:53 PM, Martin Liška wrote:
> >>> On 10/3/18 11: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.
> >>>
> >>> Heh! Thanks for the analysis.
> >>>
> >>>>
> >>>>  We have transformations that are modeled as clonning, which are
> >>>>   - inlining  (can't be disabled completely because of always inline, but -fno-inline
> >>>>     does most of stuff)
> >>>>   - cloning (disabled via -fno-ipa-cp)
> >>>>   - ipa-sra (-fno-ipa-sra)
> >>>>   - splitting (-fno-partial-inlining)
> >>>>  These should play well with Martin's tracking code
> >>>
> >>> I hope so!
> >>>
> >>>>
> >>>>  We propagate info about side effects of function:
> >>>>   - function attribute discovery (pure, const, nothrow, malloc)
> >>>>     Some of this can be disabled by -fno-ipa-pure-const, but not all
> >>>>     of it.
> >>>
> >>> Would it be possible to add option for the remaining ones?
> > 
> > Sure, I can prepare patch unless you beat me :)
> 
> Are you sure there's a call to 'analyze_function' where the analysis is done
> when one sets -fno-ipa-pure-const?

In set_nothrow_function_flags.  Probably would be good to grep for
places where node->set_XXXX_flag is used.
> 2018-11-07  Martin Liska  <mliska@suse.cz>
> 
> 	* common.opt: Add -fipa-stack-alignment flag.
> 	* doc/invoke.texi: Document it.
> 	* final.c (rest_of_clean_state): Guard stack
> 	shrinking with flag.
> 
> gcc/testsuite/ChangeLog:
> 
> 2018-11-07  Martin Liska  <mliska@suse.cz>
> 
> 	* gcc.target/i386/ipa-stack-alignment.c: New test.
> From 8691490a142228021ed65313a72d176d06966829 Mon Sep 17 00:00:00 2001
> From: marxin <mliska@suse.cz>
> Date: Wed, 7 Nov 2018 13:31:41 +0100
> Subject: [PATCH 1/2] Come up with -fipa-reference-addressable flag.
> 
> gcc/ChangeLog:
> 
> 2018-11-07  Martin Liska  <mliska@suse.cz>
> 
> 	* cgraph.h (ipa_discover_readonly_nonaddressable_vars): Rename
> 	to ...
> 	(ipa_discover_nonaddressable_vars): ... this.
> 	* common.opt: Come up with new flag -fipa-reference-addressable.
> 	* doc/invoke.texi: Document it.
> 	* ipa-reference.c (propagate): Call the renamed fn.
> 	* ipa-visibility.c (whole_program_function_and_variable_visibility):
> 	Likewise.
> 	* ipa.c (ipa_discover_readonly_nonaddressable_vars): Renamed to
> 	...
> 	(ipa_discover_nonaddressable_vars): ... this.  Discove
> 	non-addressable variables only with the newly added flag.
> 	* opts.c: Enable the newly added flag with -O1 and higher
> 	optimization level.

Hmm, the write-only and readonly flags are not handled in here?

Honza

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

[Martin Liška]

On 11/7/18 3:27 PM, Jan Hubicka wrote:
>> On 11/5/18 10:51 AM, Jan Hubicka wrote:
>>>> @honza: PING
>>>>
>>>> On 10/3/18 12:53 PM, Martin Liška wrote:
>>>>> On 10/3/18 11: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.
>>>>>
>>>>> Heh! Thanks for the analysis.
>>>>>
>>>>>>
>>>>>>  We have transformations that are modeled as clonning, which are
>>>>>>   - inlining  (can't be disabled completely because of always inline, but -fno-inline
>>>>>>     does most of stuff)
>>>>>>   - cloning (disabled via -fno-ipa-cp)
>>>>>>   - ipa-sra (-fno-ipa-sra)
>>>>>>   - splitting (-fno-partial-inlining)
>>>>>>  These should play well with Martin's tracking code
>>>>>
>>>>> I hope so!
>>>>>
>>>>>>
>>>>>>  We propagate info about side effects of function:
>>>>>>   - function attribute discovery (pure, const, nothrow, malloc)
>>>>>>     Some of this can be disabled by -fno-ipa-pure-const, but not all
>>>>>>     of it.
>>>>>
>>>>> Would it be possible to add option for the remaining ones?
>>>
>>> Sure, I can prepare patch unless you beat me :)
>>
>> Are you sure there's a call to 'analyze_function' where the analysis is done
>> when one sets -fno-ipa-pure-const?
> 
> In set_nothrow_function_flags.  Probably would be good to grep for
> places where node->set_XXXX_flag is used.

Ok, so for nothrow there are 2 extra passes (GIMPLE and RTL "nothrow" pass) that set it.
But, If I'm correct we should not case in case of C language, right?

- set_malloc_flag - only called from pass_local_pure_const pass
- set_pure_flag
  a) call from set_const_flag_1 - should be fine as it's from set_const context
  b) from pass_ipa_pure_const::
  c) from tree-profile.c: 	node->set_pure_flag (false, false); - which is fine
- set_const_flag - likewise to set_pure_const (except set_const_flag_1)

>> 2018-11-07  Martin Liska  <mliska@suse.cz>
>>
>> 	* common.opt: Add -fipa-stack-alignment flag.
>> 	* doc/invoke.texi: Document it.
>> 	* final.c (rest_of_clean_state): Guard stack
>> 	shrinking with flag.
>>
>> gcc/testsuite/ChangeLog:
>>
>> 2018-11-07  Martin Liska  <mliska@suse.cz>
>>
>> 	* gcc.target/i386/ipa-stack-alignment.c: New test.
>> From 8691490a142228021ed65313a72d176d06966829 Mon Sep 17 00:00:00 2001
>> From: marxin <mliska@suse.cz>
>> Date: Wed, 7 Nov 2018 13:31:41 +0100
>> Subject: [PATCH 1/2] Come up with -fipa-reference-addressable flag.
>>
>> gcc/ChangeLog:
>>
>> 2018-11-07  Martin Liska  <mliska@suse.cz>
>>
>> 	* cgraph.h (ipa_discover_readonly_nonaddressable_vars): Rename
>> 	to ...
>> 	(ipa_discover_nonaddressable_vars): ... this.
>> 	* common.opt: Come up with new flag -fipa-reference-addressable.
>> 	* doc/invoke.texi: Document it.
>> 	* ipa-reference.c (propagate): Call the renamed fn.
>> 	* ipa-visibility.c (whole_program_function_and_variable_visibility):
>> 	Likewise.
>> 	* ipa.c (ipa_discover_readonly_nonaddressable_vars): Renamed to
>> 	...
>> 	(ipa_discover_nonaddressable_vars): ... this.  Discove
>> 	non-addressable variables only with the newly added flag.
>> 	* opts.c: Enable the newly added flag with -O1 and higher
>> 	optimization level.
> 
> Hmm, the write-only and readonly flags are not handled in here?

You mean the ChangeLog is not mentioning that ipa_discover_nonaddressable_vars
does read-only and write-only discovery?

Martin

> 
> Honza
> 

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

[Jan Hubicka]

> 2018-11-07  Martin Liska  <mliska@suse.cz>
> 
> 	* common.opt: Add -fipa-stack-alignment flag.
> 	* doc/invoke.texi: Document it.
> 	* final.c (rest_of_clean_state): Guard stack
> 	shrinking with flag.

OK
> gcc/ChangeLog:
> 
> 2018-11-07  Martin Liska  <mliska@suse.cz>
> 
> 	* cgraph.h (ipa_discover_readonly_nonaddressable_vars): Rename
> 	to ...
> 	(ipa_discover_nonaddressable_vars): ... this.
> 	* common.opt: Come up with new flag -fipa-reference-addressable.
> 	* doc/invoke.texi: Document it.
> 	* ipa-reference.c (propagate): Call the renamed fn.
> 	* ipa-visibility.c (whole_program_function_and_variable_visibility):
> 	Likewise.
> 	* ipa.c (ipa_discover_readonly_nonaddressable_vars): Renamed to
> 	...
> 	(ipa_discover_nonaddressable_vars): ... this.  Discove
> 	non-addressable variables only with the newly added flag.
> 	* opts.c: Enable the newly added flag with -O1 and higher
> 	optimization level.
> 
> gcc/testsuite/ChangeLog:
> 
> 2018-11-07  Martin Liska  <mliska@suse.cz>
> 
> 	* gcc.dg/tree-ssa/writeonly-2.c: New test.
> ---
>  gcc/cgraph.h                                |  2 +-
>  gcc/common.opt                              |  6 +++++-
>  gcc/doc/invoke.texi                         | 10 ++++++++--
>  gcc/ipa-reference.c                         |  2 +-
>  gcc/ipa-visibility.c                        |  2 +-
>  gcc/ipa.c                                   | 11 +++++++----
>  gcc/opts.c                                  |  1 +
>  gcc/testsuite/gcc.dg/tree-ssa/writeonly-2.c | 20 ++++++++++++++++++++
>  8 files changed, 44 insertions(+), 10 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/writeonly-2.c
> 
> diff --git a/gcc/cgraph.h b/gcc/cgraph.h
> index c13d79850fa..bf65d426cda 100644
> --- a/gcc/cgraph.h
> +++ b/gcc/cgraph.h
> @@ -2403,7 +2403,7 @@ void record_references_in_initializer (tree, bool);
>  
>  /* In ipa.c  */
>  void cgraph_build_static_cdtor (char which, tree body, int priority);
> -bool ipa_discover_readonly_nonaddressable_vars (void);
> +bool ipa_discover_nonaddressable_vars (void);

I guess ipa_discover_variable_flags :)
>  
>  /* In varpool.c  */
>  tree ctor_for_folding (tree);
> diff --git a/gcc/common.opt b/gcc/common.opt
> index 2971dc21b1f..6a64b0e27d5 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -1718,7 +1718,11 @@ Perform Identical Code Folding for variables.
>  
>  fipa-reference
>  Common Report Var(flag_ipa_reference) Init(0) Optimization
> -Discover readonly and non addressable static variables.
> +Discover read-only and non addressable static variables.
> +
> +fipa-reference-addressable
> +Common Report Var(flag_ipa_reference_addressable) Init(0) Optimization
> +Discover read-only and write-only addressable variables.

I guess this should say
Discover read-only, write-only and non-addressable static variables 

OK with that change.
Honza

>  
>  fipa-matrix-reorg
>  Common Ignore
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index ae260c6ac6d..82c6fa913e8 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -412,8 +412,8 @@ Objective-C and Objective-C++ Dialects}.
>  -finline-functions  -finline-functions-called-once  -finline-limit=@var{n} @gol
>  -finline-small-functions  -fipa-cp  -fipa-cp-clone @gol
>  -fipa-bit-cp -fipa-vrp @gol
> --fipa-pta  -fipa-profile  -fipa-pure-const  -fipa-reference  -fipa-icf @gol
> --fira-algorithm=@var{algorithm} @gol
> +-fipa-pta  -fipa-profile  -fipa-pure-const  -fipa-reference  -fipa-reference-addressable @gol
> +-fipa-icf  -fira-algorithm=@var{algorithm} @gol
>  -fira-region=@var{region}  -fira-hoist-pressure @gol
>  -fira-loop-pressure  -fno-ira-share-save-slots @gol
>  -fno-ira-share-spill-slots @gol
> @@ -7866,6 +7866,7 @@ compilation time.
>  -fipa-pure-const @gol
>  -fipa-profile @gol
>  -fipa-reference @gol
> +-fipa-reference-addressable @gol
>  -fmerge-constants @gol
>  -fmove-loop-invariants @gol
>  -fomit-frame-pointer @gol
> @@ -8895,6 +8896,11 @@ Discover which static variables do not escape the
>  compilation unit.
>  Enabled by default at @option{-O} and higher.
>  
> +@item -fipa-reference-addressable
> +@opindex fipa-reference-addressable
> +Discover read-only and write-only addressable variables.
> +Enabled by default at @option{-O} and higher.
> +
>  @item -fipa-pta
>  @opindex fipa-pta
>  Perform interprocedural pointer analysis and interprocedural modification
> diff --git a/gcc/ipa-reference.c b/gcc/ipa-reference.c
> index 43bbdae5d66..2cdce3cbfa6 100644
> --- a/gcc/ipa-reference.c
> +++ b/gcc/ipa-reference.c
> @@ -705,7 +705,7 @@ propagate (void)
>    if (dump_file)
>      cgraph_node::dump_cgraph (dump_file);
>  
> -  remove_p = ipa_discover_readonly_nonaddressable_vars ();
> +  remove_p = ipa_discover_nonaddressable_vars ();
>    generate_summary ();
>  
>    /* Propagate the local information through the call graph to produce
> diff --git a/gcc/ipa-visibility.c b/gcc/ipa-visibility.c
> index 000207fa31b..1da594111f8 100644
> --- a/gcc/ipa-visibility.c
> +++ b/gcc/ipa-visibility.c
> @@ -911,7 +911,7 @@ whole_program_function_and_variable_visibility (void)
>  {
>    function_and_variable_visibility (flag_whole_program);
>    if (optimize || in_lto_p)
> -    ipa_discover_readonly_nonaddressable_vars ();
> +    ipa_discover_nonaddressable_vars ();
>    return 0;
>  }
>  
> diff --git a/gcc/ipa.c b/gcc/ipa.c
> index 3b6b5e5c8d4..eb53e7dcd06 100644
> --- a/gcc/ipa.c
> +++ b/gcc/ipa.c
> @@ -752,10 +752,10 @@ clear_addressable_bit (varpool_node *vnode, void *data ATTRIBUTE_UNUSED)
>    return false;
>  }
>  
> -/* Discover variables that have no longer address taken or that are read only
> -   and update their flags.
> +/* Discover variables that have no longer address taken, are read-only or
> +   write-only and update their flags.
>  
> -   Return true when unreachable symbol removan should be done.
> +   Return true when unreachable symbol removal should be done.
>  
>     FIXME: This can not be done in between gimplify and omp_expand since
>     readonly flag plays role on what is shared and what is not.  Currently we do
> @@ -764,8 +764,11 @@ clear_addressable_bit (varpool_node *vnode, void *data ATTRIBUTE_UNUSED)
>     make sense to do it before early optimizations.  */
>  
>  bool
> -ipa_discover_readonly_nonaddressable_vars (void)
> +ipa_discover_nonaddressable_vars (void)
>  {
> +  if (!flag_ipa_reference_addressable)
> +    return false;
> +
>    bool remove_p = false;
>    varpool_node *vnode;
>    if (dump_file)
> diff --git a/gcc/opts.c b/gcc/opts.c
> index 34c283dd765..9b9018c6c48 100644
> --- a/gcc/opts.c
> +++ b/gcc/opts.c
> @@ -451,6 +451,7 @@ static const struct default_options default_options_table[] =
>      { OPT_LEVELS_1_PLUS_NOT_DEBUG, OPT_fif_conversion2, NULL, 1 },
>      { OPT_LEVELS_1_PLUS, OPT_fipa_pure_const, NULL, 1 },
>      { OPT_LEVELS_1_PLUS, OPT_fipa_reference, NULL, 1 },
> +    { OPT_LEVELS_1_PLUS, OPT_fipa_reference_addressable, NULL, 1 },
>      { OPT_LEVELS_1_PLUS, OPT_fipa_profile, NULL, 1 },
>      { OPT_LEVELS_1_PLUS, OPT_fmerge_constants, NULL, 1 },
>      { OPT_LEVELS_1_PLUS, OPT_freorder_blocks, NULL, 1 },
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/writeonly-2.c b/gcc/testsuite/gcc.dg/tree-ssa/writeonly-2.c
> new file mode 100644
> index 00000000000..2272d15b171
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/writeonly-2.c
> @@ -0,0 +1,20 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O1 -fdump-tree-optimized -fno-ipa-reference-addressable" } */
> +static struct a {int magic1,b;} a;
> +volatile int magic2;
> +static struct b {int a,b,c,d,e,f;} magic3;
> +
> +struct b foo();
> +
> +void
> +t()
> +{
> + a.magic1 = 1;
> + magic2 = 1;
> + magic3 = foo();
> +}
> +/* { dg-final { scan-tree-dump "magic1" "optimized"} } */
> +/* { dg-final { scan-tree-dump "magic3" "optimized"} } */
> +/* { dg-final { scan-tree-dump "magic2" "optimized"} } */
> +/* { dg-final { scan-tree-dump "foo" "optimized"} } */
> + 
> -- 
> 2.19.1
> 

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

[Martin Liška]

[-- Attachment #1: Type: text/plain, Size: 217 bytes --]

Hi.

After I added 2 new options, I would like to include a new master option.
It's minimal version which only disables optimizations that we are aware of
and can potentially cause problems for live-patching.

Martin

[-- Attachment #2: 0001-Come-up-with-fvectorized-functions.patch --]
[-- Type: text/x-patch, Size: 5653 bytes --]

From dd52cd0249fc30cf6d7bf01a8826323277817b78 Mon Sep 17 00:00:00 2001
From: marxin <mliska@suse.cz>
Date: Wed, 7 Nov 2018 12:41:19 +0100
Subject: [PATCH] Come up with -fvectorized-functions.

---
 gcc/fortran/decl.c            | 33 +++++++++++++++++++++++++++
 gcc/fortran/gfortran.h        |  2 ++
 gcc/fortran/match.h           |  1 +
 gcc/fortran/parse.c           |  3 +++
 gcc/fortran/trans-intrinsic.c | 43 +++++++++++++++++++++++++++++++++++
 5 files changed, 82 insertions(+)

diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
index 2b77d950abb..938c35c508f 100644
--- a/gcc/fortran/decl.c
+++ b/gcc/fortran/decl.c
@@ -98,6 +98,9 @@ bool gfc_matching_function;
 /* Set upon parsing a !GCC$ unroll n directive for use in the next loop.  */
 int directive_unroll = -1;
 
+/* List middle-end built-ins that should be vectorized.  */
+vec<const char *> vectorized_builtins;
+
 /* If a kind expression of a component of a parameterized derived type is
    parameterized, temporarily store the expression here.  */
 static gfc_expr *saved_kind_expr = NULL;
@@ -11243,3 +11246,33 @@ gfc_match_gcc_unroll (void)
   gfc_error ("Syntax error in !GCC$ UNROLL directive at %C");
   return MATCH_ERROR;
 }
+
+/* Match a !GCC$ builtin b attributes flags form:
+
+   The parameter b is name of a middle-end built-in.
+   Flags are one of:
+     - omp-simd-notinbranch.
+
+   When we come here, we have already matched the !GCC$ builtin string.  */
+match
+gfc_match_gcc_builtin (void)
+{
+  char builtin[GFC_MAX_SYMBOL_LEN + 1];
+
+  if (gfc_match_name (builtin) != MATCH_YES)
+    return MATCH_ERROR;
+
+  gfc_gobble_whitespace ();
+  if (gfc_match ("attributes") != MATCH_YES)
+    return MATCH_ERROR;
+
+  gfc_gobble_whitespace ();
+  if (gfc_match ("omp_simd_notinbranch") != MATCH_YES)
+    return MATCH_ERROR;
+
+  char *r = XNEWVEC (char, strlen (builtin) + 32);
+  sprintf (r, "__builtin_%s", builtin);
+  vectorized_builtins.safe_push (r);
+
+  return MATCH_YES;
+}
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index d8ef35d9d6c..bb7f4dd0c4b 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -2763,6 +2763,7 @@ gfc_finalizer;
 bool gfc_in_match_data (void);
 match gfc_match_char_spec (gfc_typespec *);
 extern int directive_unroll;
+extern vec<const char *> vectorized_builtins;
 
 /* Handling Parameterized Derived Types  */
 bool gfc_insert_kind_parameter_exprs (gfc_expr *);
@@ -3501,5 +3502,6 @@ bool gfc_is_reallocatable_lhs (gfc_expr *);
 /* trans-decl.c */
 
 void finish_oacc_declare (gfc_namespace *, gfc_symbol *, bool);
+void gfc_adjust_builtins (void);
 
 #endif /* GCC_GFORTRAN_H  */
diff --git a/gcc/fortran/match.h b/gcc/fortran/match.h
index 418542bd5a6..f25ed860c06 100644
--- a/gcc/fortran/match.h
+++ b/gcc/fortran/match.h
@@ -247,6 +247,7 @@ match gfc_match_dimension (void);
 match gfc_match_external (void);
 match gfc_match_gcc_attributes (void);
 match gfc_match_gcc_unroll (void);
+match gfc_match_gcc_builtin (void);
 match gfc_match_import (void);
 match gfc_match_intent (void);
 match gfc_match_intrinsic (void);
diff --git a/gcc/fortran/parse.c b/gcc/fortran/parse.c
index 13cc6f5fccd..56d0d050bc3 100644
--- a/gcc/fortran/parse.c
+++ b/gcc/fortran/parse.c
@@ -1072,6 +1072,7 @@ decode_gcc_attribute (void)
 
   match ("attributes", gfc_match_gcc_attributes, ST_ATTR_DECL);
   match ("unroll", gfc_match_gcc_unroll, ST_NONE);
+  match ("builtin", gfc_match_gcc_builtin, ST_NONE);
 
   /* All else has failed, so give up.  See if any of the matchers has
      stored an error message of some sort.  */
@@ -5663,6 +5664,8 @@ parse_progunit (gfc_statement st)
   gfc_state_data *p;
   int n;
 
+  gfc_adjust_builtins ();
+
   if (gfc_new_block
       && gfc_new_block->abr_modproc_decl
       && gfc_new_block->attr.function)
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 4ae2b3252b5..0417e039a39 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -597,7 +597,50 @@ define_quad_builtin (const char *name, tree type, bool is_const)
   return fndecl;
 }
 
+/* Add SIMD attribute for FNDECL built-in if the built-in
+   name is in VECTORIZED_BUILTINS.  */
 
+static void
+add_simd_flag_for_built_in (tree fndecl)
+{
+  if (fndecl == NULL_TREE)
+    return;
+
+  const char *name = IDENTIFIER_POINTER (DECL_NAME (fndecl));
+  for (unsigned i = 0; i < vectorized_builtins.length (); i++)
+    if (strcmp (vectorized_builtins[i], name) == 0)
+      {
+	DECL_ATTRIBUTES (fndecl)
+	  = tree_cons (get_identifier ("omp declare simd"),
+		       build_tree_list (NULL_TREE,
+					build_omp_clause (UNKNOWN_LOCATION,
+							  OMP_CLAUSE_NOTINBRANCH)),
+		       DECL_ATTRIBUTES (fndecl));
+	return;
+      }
+}
+
+void
+gfc_adjust_builtins (void)
+{
+  gfc_intrinsic_map_t *m;
+  for (m = gfc_intrinsic_map;
+       m->id != GFC_ISYM_NONE || m->double_built_in != END_BUILTINS; m++)
+    {
+      add_simd_flag_for_built_in (m->real4_decl);
+      add_simd_flag_for_built_in (m->complex4_decl);
+      add_simd_flag_for_built_in (m->real8_decl);
+      add_simd_flag_for_built_in (m->complex8_decl);
+      add_simd_flag_for_built_in (m->real10_decl);
+      add_simd_flag_for_built_in (m->complex10_decl);
+      add_simd_flag_for_built_in (m->real16_decl);
+      add_simd_flag_for_built_in (m->complex16_decl);
+      add_simd_flag_for_built_in (m->real16_decl);
+      add_simd_flag_for_built_in (m->complex16_decl);
+    }
+
+  vectorized_builtins.truncate (0);
+}
 
 /* Initialize function decls for library functions.  The external functions
    are created as required.  Builtin functions are added here.  */
-- 
2.19.1

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

[Qing Zhao]

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, could you please explain a little bit more on the problem?

Thanks.

Qing

> On Nov 9, 2018, at 9:33 AM, Martin Liška <mliska@suse.cz> wrote:
> 
> Hi.
> 
> After I added 2 new options, I would like to include a new master option.
> It's minimal version which only disables optimizations that we are aware of
> and can potentially cause problems for live-patching.
> 
> Martin
> <0001-Come-up-with-fvectorized-functions.patch>

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

[Martin Liška]

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.

> 
> 1. do we still need new options to disable the following:
>    A. unreachable code/variable removal? 

I hope it's guarded with newly added option -fipa-reference-addressable. Correct me
if I'm wrong.

>    B. Visibility changes with -flto and/or -fwhole-program?

The options are not used in linux kernel, thus I didn't consider.

> 
> 2. for this new patch, could you please explain a little bit more on the problem?

We want to enable a single option that will disable all possible (and future) optimizations
that influence live patching.

Martin

> 
> Thanks.
> 
> Qing
> 
>> On Nov 9, 2018, at 9:33 AM, Martin Liška <mliska@suse.cz> wrote:
>>
>> Hi.
>>
>> After I added 2 new options, I would like to include a new master option.
>> It's minimal version which only disables optimizations that we are aware of
>> and can potentially cause problems for live-patching.
>>
>> Martin
>> <0001-Come-up-with-fvectorized-functions.patch>
> 

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

[Qing Zhao]

Hi,


> On Nov 10, 2018, at 2:51 AM, Martin Liška <mliska@suse.cz> 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.
> 
>> 
>> 1. do we still need new options to disable the following:
>>   A. unreachable code/variable removal? 
> 
> I hope it's guarded with newly added option -fipa-reference-addressable. Correct me
> if I'm wrong.

The followings are some previous discussions on this:

“
>>> 
>>> We perform discovery of functions/variables with no address taken and
>>> optimizations that are not valid otherwise such as duplicating them
>>> or doing skipping them for alias analysis (no flag to disable)
>> 
>> Can you be please more verbose here? What optimizations do you mean?

See ipa_discover_readonly_nonaddressable_vars. If addressable bit is
cleared we start analyzing uses of the variable via ipa_reference or so.
If writeonly bit is set, we start removing writes to the variable and if
readonly bit is set we skip any analysis about whether vairable changed.
“

the new -fipa-reference-addressable is to control the above,  seems not the unreachable code/variable removal?

> 
>>   B. Visibility changes with -flto and/or -fwhole-program?
> 
> The options are not used in linux kernel, thus I didn't consider.

Okay, I see.

> 
>> 
>> 2. for this new patch, could you please explain a little bit more on the problem?
> 
> We want to enable a single option that will disable all possible (and future) optimizations
> that influence live patching.

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=
+Common Report Joined RejectNegative Enum(live_patching_level) Var(flag_live_patching) Init(LIVE_NONE)
+-flive-patching=[inline-only-static|inline-clone]      Control optimizations to provide a safe comp for live-patching purpose.

the implementation for -flive-patching=inline-clone (the default) is exactly as yours,  the new level -flive-patching=inline-only-static
is to only enable inlining of static function for live patching, which is important for multiple-processes live patching to control memory
consumption. 

(please see my 2nd version of the -flive-patching proposal).

I will send out my complete patch in another email.

thanks.

Qing

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

[Martin Liška]

On 11/12/18 3:28 AM, Qing Zhao wrote:
> Hi,
> 
> 
>> On Nov 10, 2018, at 2:51 AM, Martin Liška <mliska@suse.cz> 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.
>>
>>>
>>> 1. do we still need new options to disable the following:
>>>   A. unreachable code/variable removal? 
>>
>> I hope it's guarded with newly added option -fipa-reference-addressable. Correct me
>> if I'm wrong.
> 
> The followings are some previous discussions on this:
> 
> “
>>>>
>>>> We perform discovery of functions/variables with no address taken and
>>>> optimizations that are not valid otherwise such as duplicating them
>>>> or doing skipping them for alias analysis (no flag to disable)
>>>
>>> Can you be please more verbose here? What optimizations do you mean?
> 
> See ipa_discover_readonly_nonaddressable_vars. If addressable bit is
> cleared we start analyzing uses of the variable via ipa_reference or so.
> If writeonly bit is set, we start removing writes to the variable and if
> readonly bit is set we skip any analysis about whether vairable changed.
> “
> 
> the new -fipa-reference-addressable is to control the above,  seems not the unreachable code/variable removal?
> 
>>
>>>   B. Visibility changes with -flto and/or -fwhole-program?
>>
>> The options are not used in linux kernel, thus I didn't consider.
> 
> Okay, I see.
> 
>>
>>>
>>> 2. for this new patch, could you please explain a little bit more on the problem?
>>
>> We want to enable a single option that will disable all possible (and future) optimizations
>> that influence live patching.
> 
> 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=
> +Common Report Joined RejectNegative Enum(live_patching_level) Var(flag_live_patching) Init(LIVE_NONE)
> +-flive-patching=[inline-only-static|inline-clone]      Control optimizations to provide a safe comp for live-patching purpose.
> 
> the implementation for -flive-patching=inline-clone (the default) is exactly as yours,  the new level -flive-patching=inline-only-static
> is to only enable inlining of static function for live patching, which is important for multiple-processes live patching to control memory
> consumption. 
> 
> (please see my 2nd version of the -flive-patching proposal).
> 
> I will send out my complete patch in another email.

Hi, sure, works for me. Let's make 2 level option.

Martin

> 
> thanks.
> 
> Qing
> 
> 

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

[Qing Zhao]

> On Nov 12, 2018, at 2:53 AM, Martin Liška <mliska@suse.cz> 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=
>> +Common Report Joined RejectNegative Enum(live_patching_level) Var(flag_live_patching) Init(LIVE_NONE)
>> +-flive-patching=[inline-only-static|inline-clone]      Control optimizations to provide a safe comp for live-patching purpose.
>> 
>> the implementation for -flive-patching=inline-clone (the default) is exactly as yours,  the new level -flive-patching=inline-only-static
>> is to only enable inlining of static function for live patching, which is important for multiple-processes live patching to control memory
>> consumption. 
>> 
>> (please see my 2nd version of the -flive-patching proposal).
>> 
>> I will send out my complete patch in another email.
> 
> Hi, sure, works for me. Let's make 2 level option.

thank you.

I will send the patch tomorrow.

Qing
> 
> Martin

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

[Qing Zhao]

[-- Attachment #1: Type: text/plain, Size: 1225 bytes --]

Hi,


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 multiple-level control on how many of the
     optimizations are enabled by users' request.  The LEVEL argument
     should be one of the following:

     'inline-only-static'

          Only enable inlining of static functions, disable all other
          ipa optimizations/analyses.  As a result, when patching a
          static routine, all its callers need to be patches as well.

     'inline-clone'

          Only enable inlining and all optimizations that internally
          create clone, for example, cloning, ipa-sra, partial inlining,
          etc.; disable all other ipa optimizations/analyses.  As a
          result, when patching a routine, all its callers and its
          clones' callers need to be patched as well.

     When -flive-patching specified without any value, the default value
     is "inline-clone".

     This flag is disabled by default.

let me know your comments and suggestions on the implementation.

thanks a lot.

Qing


[-- Attachment #2: flive-patching.patch --]
[-- Type: application/octet-stream, Size: 9978 bytes --]

From 6d77e2139cd5fbbb408a3c6d94ed79f5759abde8 Mon Sep 17 00:00:00 2001
From: qing zhao <qing.zhao@oracle.com>
Date: Tue, 13 Nov 2018 09:40:17 -0800
Subject: [PATCH] Add -flive-patching to support live patching

---
 gcc/cif-code.def                       |  6 ++++
 gcc/common.opt                         | 18 ++++++++++
 gcc/doc/invoke.texi                    | 33 +++++++++++++++++-
 gcc/flag-types.h                       |  8 +++++
 gcc/ipa-inline.c                       |  6 ++++
 gcc/opts.c                             | 64 ++++++++++++++++++++++++++++++++++
 gcc/testsuite/gcc.dg/live-patching-1.c | 22 ++++++++++++
 7 files changed, 156 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/live-patching-1.c

diff --git a/gcc/cif-code.def b/gcc/cif-code.def
index 19a7621..dffe15f 100644
--- a/gcc/cif-code.def
+++ b/gcc/cif-code.def
@@ -132,6 +132,12 @@ DEFCIFCODE(USES_COMDAT_LOCAL, CIF_FINAL_ERROR,
 DEFCIFCODE(ATTRIBUTE_MISMATCH, CIF_FINAL_ERROR,
 	   N_("function attribute mismatch"))
 
+/* We can't inline because the user requests only static functions 
+   but the function has external linkage for live patching purpose.  */
+DEFCIFCODE(EXTERN_LIVE_ONLY_STATIC, CIF_FINAL_ERROR,
+	   N_("function has external linkage when the user requests only"
+	      " inlining static for live patching"))
+
 /* We proved that the call is unreachable.  */
 DEFCIFCODE(UNREACHABLE, CIF_FINAL_ERROR,
 	   N_("unreachable"))
diff --git a/gcc/common.opt b/gcc/common.opt
index 98e8eb0..346a361 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2152,6 +2152,24 @@ starts and when the destructor finishes.
 flifetime-dse=
 Common Joined RejectNegative UInteger Var(flag_lifetime_dse) Optimization IntegerRange(0, 2)
 
+flive-patching
+Common RejectNegative Alias(flive-patching=,inline-clone) Optimization
+
+flive-patching=
+Common Report Joined RejectNegative Enum(live_patching_level) Var(flag_live_patching) Init(LIVE_NONE) Optimization
+-flive-patching=[inline-only-static|inline-clone]	Control ipa optimizations to provide a 
+safe compilation for live-patching. At the same time, provides multiple-level control on the  
+enabled optimizations. 
+
+Enum
+Name(live_patching_level) Type(enum live_patching_level) UnknownError(unknown Live-Patching Level %qs)
+
+EnumValue
+Enum(live_patching_level) String(inline-only-static) Value(LIVE_INLINE_ONLY_STATIC)
+
+EnumValue
+Enum(live_patching_level) String(inline-clone) Value(LIVE_INLINE_CLONE)
+
 flive-range-shrinkage
 Common Report Var(flag_live_range_shrinkage) Init(0) Optimization
 Relief of register pressure through live range shrinkage.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 4ea93a7..38c5ae3 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -411,10 +411,11 @@ Objective-C and Objective-C++ Dialects}.
 -fgcse-sm  -fhoist-adjacent-loads  -fif-conversion @gol
 -fif-conversion2  -findirect-inlining @gol
 -finline-functions  -finline-functions-called-once  -finline-limit=@var{n} @gol
--finline-small-functions  -fipa-cp  -fipa-cp-clone @gol
+-finline-small-functions -fipa-cp  -fipa-cp-clone @gol
 -fipa-bit-cp -fipa-vrp @gol
 -fipa-pta  -fipa-profile  -fipa-pure-const  -fipa-reference  -fipa-reference-addressable @gol
 -fipa-stack-alignment  -fipa-icf  -fira-algorithm=@var{algorithm} @gol
+-flive-patching=@var{level} @gol
 -fira-region=@var{region}  -fira-hoist-pressure @gol
 -fira-loop-pressure  -fno-ira-share-save-slots @gol
 -fno-ira-share-spill-slots @gol
@@ -8982,6 +8983,36 @@ equivalences that are found only by GCC and equivalences found only by Gold.
 
 This flag is enabled by default at @option{-O2} and @option{-Os}.
 
+@item -flive-patching=@var{level}
+@opindex flive-patching
+Control GCC's optimizations to provide a safe compilation for live-patching.
+Provides multiple-level control on how many of the optimizations are enabled
+by users' request. 
+The @var{level} argument should be one of the following:
+
+@table @samp
+
+@item inline-only-static
+
+Only enable inlining of static functions, disable all other ipa 
+optimizations/analyses. As a result, when patching a static routine,
+all its callers need to be patches as well.
+
+@item inline-clone 
+
+Only enable inlining and all optimizations that internally create clone,
+for example, cloning, ipa-sra, partial inlining, etc.; disable all
+other ipa optimizations/analyses.
+As a result, when patching a routine, all its callers and its clones'
+callers need to be patched as well.
+
+@end table
+
+When -flive-patching specified without any value, the default value
+is "inline-clone".
+
+This flag is disabled by default.
+
 @item -fisolate-erroneous-paths-dereference
 @opindex fisolate-erroneous-paths-dereference
 Detect paths that trigger erroneous or undefined behavior due to
diff --git a/gcc/flag-types.h b/gcc/flag-types.h
index 500f663..72e0f0f 100644
--- a/gcc/flag-types.h
+++ b/gcc/flag-types.h
@@ -123,6 +123,14 @@ enum stack_reuse_level
   SR_ALL
 };
 
+/* The live patching level. */
+enum live_patching_level
+{
+  LIVE_NONE = 0,
+  LIVE_INLINE_ONLY_STATIC,
+  LIVE_INLINE_CLONE
+};
+
 /* The algorithm used for basic block reordering.  */
 enum reorder_blocks_algorithm
 {
diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
index e04ede7..fadb437 100644
--- a/gcc/ipa-inline.c
+++ b/gcc/ipa-inline.c
@@ -377,6 +377,12 @@ can_inline_edge_p (struct cgraph_edge *e, bool report,
       e->inline_failed = CIF_ATTRIBUTE_MISMATCH;
       inlinable = false;
     }
+  else if (callee->externally_visible 
+	   && flag_live_patching == LIVE_INLINE_ONLY_STATIC) 
+    {
+      e->inline_failed = CIF_EXTERN_LIVE_ONLY_STATIC;
+      inlinable = false;
+    }
   if (!inlinable && report)
     report_inline_failed_reason (e);
   return inlinable;
diff --git a/gcc/opts.c b/gcc/opts.c
index e21967b..110d4c8 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -691,6 +691,60 @@ default_options_optimization (struct gcc_options *opts,
 			 lang_mask, handlers, loc, dc);
 }
 
+/* Control ipa optimizations based on different live patching LEVEL */
+static void
+control_optimizations_for_live_patching (struct gcc_options *opts, 
+					 struct gcc_options *opts_set, 
+					 enum live_patching_level level)
+{
+  gcc_assert (level > LIVE_NONE);
+
+  switch (level)
+    {
+    case LIVE_INLINE_ONLY_STATIC:
+      if (!opts_set->x_flag_ipa_cp_clone)
+        opts->x_flag_ipa_cp_clone = 0;      
+      if (!opts_set->x_flag_ipa_sra)
+        opts->x_flag_ipa_sra = 0;
+      if (!opts_set->x_flag_partial_inlining)
+        opts->x_flag_partial_inlining = 0;
+      if (!opts_set->x_flag_ipa_cp)
+        opts->x_flag_ipa_cp = 0;      
+      /* FALLTHROUGH */
+    case LIVE_INLINE_CLONE:
+      /* live patching should disable whole-program optimization.  */
+      if (!opts_set->x_flag_whole_program)
+        opts->x_flag_whole_program = 0;
+      /* visibility change should be excluded by !flag_whole_program 
+	 && !in_lto_p && !flag_ipa_cp_clone && !flag_ipa_sra 
+	 && !flag_partial_inlining.  */
+      if (!opts_set->x_flag_ipa_pta)
+        opts->x_flag_ipa_pta = 0;
+      if (!opts_set->x_flag_ipa_reference)
+        opts->x_flag_ipa_reference = 0;
+      if (!opts_set->x_flag_ipa_ra)
+        opts->x_flag_ipa_ra = 0;
+      if (!opts_set->x_flag_ipa_icf)
+        opts->x_flag_ipa_icf = 0;
+      if (!opts_set->x_flag_ipa_bit_cp)
+        opts->x_flag_ipa_bit_cp = 0;
+      if (!opts_set->x_flag_ipa_vrp)
+        opts->x_flag_ipa_vrp = 0;
+      if (!opts_set->x_flag_ipa_pure_const)
+        opts->x_flag_ipa_pure_const = 0;
+      /* unreachable code removal.  */
+      /* discovery of functions/variables with no address taken.  */
+      if (!opts_set->x_flag_ipa_reference_addressable)
+        opts->x_flag_ipa_reference_addressable = 0;
+      /* ipa stack alignment propagation.  */
+      if (!opts_set->x_flag_ipa_stack_alignment)
+        opts->x_flag_ipa_stack_alignment = 0;
+      break;
+    default: 
+      gcc_assert (0);  
+    }
+}
+
 /* After all options at LOC have been read into OPTS and OPTS_SET,
    finalize settings of those options and diagnose incompatible
    combinations.  */
@@ -1040,6 +1094,10 @@ finish_options (struct gcc_options *opts, struct gcc_options *opts_set,
   if ((opts->x_flag_sanitize & SANITIZE_KERNEL_ADDRESS) && opts->x_flag_tm)
     sorry ("transactional memory is not supported with "
 	   "%<-fsanitize=kernel-address%>");
+
+  /* Currently live patching is not support for LTO.  */
+  if (opts->x_flag_live_patching && in_lto_p) 
+    sorry ("live patching is not supported with LTO");
 }
 
 #define LEFT_COLUMN	27
@@ -2266,6 +2324,12 @@ common_handle_option (struct gcc_options *opts,
 	(&opts->x_flag_instrument_functions_exclude_files, arg);
       break;
 
+    case OPT_flive_patching_:
+      if (value)
+    	control_optimizations_for_live_patching (opts, opts_set,
+						 opts->x_flag_live_patching);
+      break;
+
     case OPT_fmessage_length_:
       pp_set_line_maximum_length (dc->printer, value);
       diagnostic_set_caret_max_width (dc, value);
diff --git a/gcc/testsuite/gcc.dg/live-patching-1.c b/gcc/testsuite/gcc.dg/live-patching-1.c
new file mode 100644
index 0000000..6a1ea38
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/live-patching-1.c
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -flive-patching=inline-only-static -fdump-ipa-inline" } */
+
+extern int sum, n, m;
+
+int foo (int a)
+{
+  return a + n;
+}
+
+static int bar (int b)
+{
+  return b * m;
+}
+
+int main()
+{
+  sum = foo (m) + bar (n); 
+  return 0;
+}
+
+/* { dg-final { scan-ipa-dump "foo/0 function has external linkage when the user requests only inlining static for live patching"  "inline" } } */
-- 
1.9.1

[-- Attachment #3: Type: text/plain, Size: 1252 bytes --]



> On Nov 12, 2018, at 4:29 PM, Qing Zhao <qing.zhao@oracle.com> wrote:
> 
> 
>> On Nov 12, 2018, at 2:53 AM, Martin Liška <mliska@suse.cz> 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=
>>> +Common Report Joined RejectNegative Enum(live_patching_level) Var(flag_live_patching) Init(LIVE_NONE)
>>> +-flive-patching=[inline-only-static|inline-clone]      Control optimizations to provide a safe comp for live-patching purpose.
>>> 
>>> the implementation for -flive-patching=inline-clone (the default) is exactly as yours,  the new level -flive-patching=inline-only-static
>>> is to only enable inlining of static function for live patching, which is important for multiple-processes live patching to control memory
>>> consumption. 
>>> 
>>> (please see my 2nd version of the -flive-patching proposal).
>>> 
>>> I will send out my complete patch in another email.
>> 
>> Hi, sure, works for me. Let's make 2 level option.
> 
> thank you.
> 
> I will send the patch tomorrow.
> 
> Qing
>> 
>> Martin
> 

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

[Miroslav Benes]

On Tue, 13 Nov 2018, Qing Zhao wrote:

> Hi,

Hi, 
 
> 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 multiple-level control on how many of the
>      optimizations are enabled by users' request.  The LEVEL argument
>      should be one of the following:
> 
>      'inline-only-static'
> 
>           Only enable inlining of static functions, disable all other
>           ipa optimizations/analyses.  As a result, when patching a
>           static routine, all its callers need to be patches as well.
> 
>      'inline-clone'
> 
>           Only enable inlining and all optimizations that internally
>           create clone, for example, cloning, ipa-sra, partial inlining,
>           etc.; disable all other ipa optimizations/analyses.  As a
>           result, when patching a routine, all its callers and its
>           clones' callers need to be patched as well.

Based on our previous discussion I assume that "clone" optimizations are 
safe (for LP) and the others are not. Anyway I'd welcome a note mentioning 
that disabled optimizations are dangerous for LP.

I know it may be the same for you, but it is not for me as a GCC user. 
"internally create clone" sounds very... well, internal. It does not 
describe the option much for ordinary user whow has no knowledge about GCC 
internals.

So could you rephrase it a bit, please?

>      When -flive-patching specified without any value, the default value
>      is "inline-clone".
> 
>      This flag is disabled by default.
> 
> let me know your comments and suggestions on the implementation.

I compared it to Martin's patch and ipa-icf-variables is not covered in 
yours (I may have missed something).

Thanks,
Miroslav

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

[Qing Zhao]

[-- Attachment #1: Type: text/plain, Size: 4506 bytes --]

Hi,

> On Nov 13, 2018, at 1:18 PM, Miroslav Benes <mbenes@suse.cz> 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 multiple-level control on how many of the
>>     optimizations are enabled by users' request.  The LEVEL argument
>>     should be one of the following:
>> 
>>     'inline-only-static'
>> 
>>          Only enable inlining of static functions, disable all other
>>          ipa optimizations/analyses.  As a result, when patching a
>>          static routine, all its callers need to be patches as well.
>> 
>>     'inline-clone'
>> 
>>          Only enable inlining and all optimizations that internally
>>          create clone, for example, cloning, ipa-sra, partial inlining,
>>          etc.; disable all other ipa optimizations/analyses.  As a
>>          result, when patching a routine, all its callers and its
>>          clones' callers need to be patched as well.
> 
> Based on our previous discussion I assume that "clone" optimizations are 
> safe (for LP) and the others are not. Anyway I'd welcome a note mentioning 
> that disabled optimizations are dangerous for LP.

actually, I don’t think that those disabled optimizations are “dangerous” for live-patching. one of the major reasons we disable them
is because that currently the compiler does NOT provide a good way to compute the impacted function list for those optimizations.
therefore, we disable them at this time. 

many of them could be enabled too if the compiler can report the impacted function list accurately in the future.



> 
> I know it may be the same for you, but it is not for me as a GCC user. 
> "internally create clone" sounds very... well, internal. It does not 
> describe the option much for ordinary user whow has no knowledge about GCC 
> internals.
> 
> So could you rephrase it a bit, please?

I tried to make this clear. please see the following:

'-flive-patching=LEVEL'
     Control GCC's optimizations to provide a safe compilation for
     live-patching.

     If the compiler's optimization uses a function's body or
     information extracted from its body to optimize/change another
     function, the latter is called an impacted function of the former.
     If a function is patched, its impacted functions should be patched
     too.

     The impacted functions are decided by the compiler's
     interprocedural optimizations.  For example, inlining a function
     into its caller, cloning a function and changing its caller to call
     this new clone, or extracting a function's pureness/constness
     information to optimize its direct or indirect callers, etc.

     Usually, the more ipa optimizations enabled, the larger the number
     of impacted functions for each function.  In order to control the
     number of impacted functions and computed the list of impacted
     function easily, we provide control to partially enable ipa
     optimizations on two different levels.

     The LEVEL argument should be one of the following:

     'inline-only-static'

          Only enable inlining of static functions, disable all other
          interprocedural optimizations/analyses.  As a result, when
          patching a static routine, all its callers need to be patches
          as well.

     'inline-clone'

          Only enable inlining and cloning optimizations, which includes
          inlining, cloning, interprocedural scalar replacement of
          aggregates and partial inlining.  Disable all other
          interprocedural optimizations/analyses.  As a result, when
          patching a routine, all its callers and its clones' callers
          need to be patched as well.

     When -flive-patching specified without any value, the default value
     is "inline-clone".

     This flag is disabled by default.


> 
>>     When -flive-patching specified without any value, the default value
>>     is "inline-clone".
>> 
>>     This flag is disabled by default.
>> 
>> let me know your comments and suggestions on the implementation.
> 
> I compared it to Martin's patch and ipa-icf-variables is not covered in 
> yours (I may have missed something).

Yes, you are right. I added this into my patch.

I am attaching the new patch here.


[-- Attachment #2: flive-patching.patch --]
[-- Type: application/octet-stream, Size: 11025 bytes --]

From c0785675eb29599754aaf11c70901c12dd3ea821 Mon Sep 17 00:00:00 2001
From: qing zhao <qing.zhao@oracle.com>
Date: Tue, 13 Nov 2018 13:02:57 -0800
Subject: [PATCH] Add -flive-patching to support live patching

---
 gcc/cif-code.def                       |  6 +++
 gcc/common.opt                         | 18 +++++++++
 gcc/doc/invoke.texi                    | 49 +++++++++++++++++++++++-
 gcc/flag-types.h                       |  8 ++++
 gcc/ipa-inline.c                       |  6 +++
 gcc/opts.c                             | 68 ++++++++++++++++++++++++++++++++++
 gcc/testsuite/gcc.dg/live-patching-1.c | 22 +++++++++++
 7 files changed, 176 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/live-patching-1.c

diff --git a/gcc/cif-code.def b/gcc/cif-code.def
index 19a7621..dffe15f 100644
--- a/gcc/cif-code.def
+++ b/gcc/cif-code.def
@@ -132,6 +132,12 @@ DEFCIFCODE(USES_COMDAT_LOCAL, CIF_FINAL_ERROR,
 DEFCIFCODE(ATTRIBUTE_MISMATCH, CIF_FINAL_ERROR,
 	   N_("function attribute mismatch"))
 
+/* We can't inline because the user requests only static functions 
+   but the function has external linkage for live patching purpose.  */
+DEFCIFCODE(EXTERN_LIVE_ONLY_STATIC, CIF_FINAL_ERROR,
+	   N_("function has external linkage when the user requests only"
+	      " inlining static for live patching"))
+
 /* We proved that the call is unreachable.  */
 DEFCIFCODE(UNREACHABLE, CIF_FINAL_ERROR,
 	   N_("unreachable"))
diff --git a/gcc/common.opt b/gcc/common.opt
index 98e8eb0..346a361 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2152,6 +2152,24 @@ starts and when the destructor finishes.
 flifetime-dse=
 Common Joined RejectNegative UInteger Var(flag_lifetime_dse) Optimization IntegerRange(0, 2)
 
+flive-patching
+Common RejectNegative Alias(flive-patching=,inline-clone) Optimization
+
+flive-patching=
+Common Report Joined RejectNegative Enum(live_patching_level) Var(flag_live_patching) Init(LIVE_NONE) Optimization
+-flive-patching=[inline-only-static|inline-clone]	Control ipa optimizations to provide a 
+safe compilation for live-patching. At the same time, provides multiple-level control on the  
+enabled optimizations. 
+
+Enum
+Name(live_patching_level) Type(enum live_patching_level) UnknownError(unknown Live-Patching Level %qs)
+
+EnumValue
+Enum(live_patching_level) String(inline-only-static) Value(LIVE_INLINE_ONLY_STATIC)
+
+EnumValue
+Enum(live_patching_level) String(inline-clone) Value(LIVE_INLINE_CLONE)
+
 flive-range-shrinkage
 Common Report Var(flag_live_range_shrinkage) Init(0) Optimization
 Relief of register pressure through live range shrinkage.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 4ea93a7..c473049 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -411,10 +411,11 @@ Objective-C and Objective-C++ Dialects}.
 -fgcse-sm  -fhoist-adjacent-loads  -fif-conversion @gol
 -fif-conversion2  -findirect-inlining @gol
 -finline-functions  -finline-functions-called-once  -finline-limit=@var{n} @gol
--finline-small-functions  -fipa-cp  -fipa-cp-clone @gol
+-finline-small-functions -fipa-cp  -fipa-cp-clone @gol
 -fipa-bit-cp -fipa-vrp @gol
 -fipa-pta  -fipa-profile  -fipa-pure-const  -fipa-reference  -fipa-reference-addressable @gol
 -fipa-stack-alignment  -fipa-icf  -fira-algorithm=@var{algorithm} @gol
+-flive-patching=@var{level} @gol
 -fira-region=@var{region}  -fira-hoist-pressure @gol
 -fira-loop-pressure  -fno-ira-share-save-slots @gol
 -fno-ira-share-spill-slots @gol
@@ -8982,6 +8983,52 @@ equivalences that are found only by GCC and equivalences found only by Gold.
 
 This flag is enabled by default at @option{-O2} and @option{-Os}.
 
+@item -flive-patching=@var{level}
+@opindex flive-patching
+Control GCC's optimizations to provide a safe compilation for live-patching.
+
+If the compiler's optimization uses a function's body or information extracted 
+from its body to optimize/change another function, the latter is called an
+impacted function of the former.  If a function is patched, its impacted
+functions should be patched too.
+
+The impacted functions are decided by the compiler's interprocedural
+optimizations. For example, inlining a function into its caller, cloning 
+a function and changing its caller to call this new clone, or extracting
+a function's pureness/constness information to optimize its direct or 
+indirect callers, etc.
+
+Usually, the more ipa optimizations enabled, the larger the number of
+impacted functions for each function. In order to control the number of
+impacted functions and computed the list of impacted function easily, 
+we provide control to partially enable ipa optimizations on two different 
+levels.
+
+The @var{level} argument should be one of the following:
+
+@table @samp
+
+@item inline-only-static
+
+Only enable inlining of static functions, disable all other interprocedural 
+optimizations/analyses. As a result, when patching a static routine,
+all its callers need to be patches as well.
+
+@item inline-clone 
+
+Only enable inlining and cloning optimizations, which includes inlining, 
+cloning, interprocedural scalar replacement of aggregates and partial inlining.
+Disable all other interprocedural optimizations/analyses.
+As a result, when patching a routine, all its callers and its clones'
+callers need to be patched as well.
+
+@end table
+
+When -flive-patching specified without any value, the default value
+is "inline-clone".
+
+This flag is disabled by default.
+
 @item -fisolate-erroneous-paths-dereference
 @opindex fisolate-erroneous-paths-dereference
 Detect paths that trigger erroneous or undefined behavior due to
diff --git a/gcc/flag-types.h b/gcc/flag-types.h
index 500f663..72e0f0f 100644
--- a/gcc/flag-types.h
+++ b/gcc/flag-types.h
@@ -123,6 +123,14 @@ enum stack_reuse_level
   SR_ALL
 };
 
+/* The live patching level. */
+enum live_patching_level
+{
+  LIVE_NONE = 0,
+  LIVE_INLINE_ONLY_STATIC,
+  LIVE_INLINE_CLONE
+};
+
 /* The algorithm used for basic block reordering.  */
 enum reorder_blocks_algorithm
 {
diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
index e04ede7..fadb437 100644
--- a/gcc/ipa-inline.c
+++ b/gcc/ipa-inline.c
@@ -377,6 +377,12 @@ can_inline_edge_p (struct cgraph_edge *e, bool report,
       e->inline_failed = CIF_ATTRIBUTE_MISMATCH;
       inlinable = false;
     }
+  else if (callee->externally_visible 
+	   && flag_live_patching == LIVE_INLINE_ONLY_STATIC) 
+    {
+      e->inline_failed = CIF_EXTERN_LIVE_ONLY_STATIC;
+      inlinable = false;
+    }
   if (!inlinable && report)
     report_inline_failed_reason (e);
   return inlinable;
diff --git a/gcc/opts.c b/gcc/opts.c
index e21967b..281f9f4 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -691,6 +691,64 @@ default_options_optimization (struct gcc_options *opts,
 			 lang_mask, handlers, loc, dc);
 }
 
+/* Control ipa optimizations based on different live patching LEVEL */
+static void
+control_optimizations_for_live_patching (struct gcc_options *opts, 
+					 struct gcc_options *opts_set, 
+					 enum live_patching_level level)
+{
+  gcc_assert (level > LIVE_NONE);
+
+  switch (level)
+    {
+    case LIVE_INLINE_ONLY_STATIC:
+      if (!opts_set->x_flag_ipa_cp_clone)
+        opts->x_flag_ipa_cp_clone = 0;      
+      if (!opts_set->x_flag_ipa_sra)
+        opts->x_flag_ipa_sra = 0;
+      if (!opts_set->x_flag_partial_inlining)
+        opts->x_flag_partial_inlining = 0;
+      if (!opts_set->x_flag_ipa_cp)
+        opts->x_flag_ipa_cp = 0;      
+      /* FALLTHROUGH */
+    case LIVE_INLINE_CLONE:
+      /* live patching should disable whole-program optimization.  */
+      if (!opts_set->x_flag_whole_program)
+        opts->x_flag_whole_program = 0;
+      /* visibility change should be excluded by !flag_whole_program 
+	 && !in_lto_p && !flag_ipa_cp_clone && !flag_ipa_sra 
+	 && !flag_partial_inlining.  */
+      if (!opts_set->x_flag_ipa_pta)
+        opts->x_flag_ipa_pta = 0;
+      if (!opts_set->x_flag_ipa_reference)
+        opts->x_flag_ipa_reference = 0;
+      if (!opts_set->x_flag_ipa_ra)
+        opts->x_flag_ipa_ra = 0;
+      if (!opts_set->x_flag_ipa_icf)
+        opts->x_flag_ipa_icf = 0;
+      if (!opts_set->x_flag_ipa_icf_functions)
+        opts->x_flag_ipa_icf_functions = 0;
+      if (!opts_set->x_flag_ipa_icf_variables)
+        opts->x_flag_ipa_icf_variables = 0;
+      if (!opts_set->x_flag_ipa_bit_cp)
+        opts->x_flag_ipa_bit_cp = 0;
+      if (!opts_set->x_flag_ipa_vrp)
+        opts->x_flag_ipa_vrp = 0;
+      if (!opts_set->x_flag_ipa_pure_const)
+        opts->x_flag_ipa_pure_const = 0;
+      /* unreachable code removal.  */
+      /* discovery of functions/variables with no address taken.  */
+      if (!opts_set->x_flag_ipa_reference_addressable)
+        opts->x_flag_ipa_reference_addressable = 0;
+      /* ipa stack alignment propagation.  */
+      if (!opts_set->x_flag_ipa_stack_alignment)
+        opts->x_flag_ipa_stack_alignment = 0;
+      break;
+    default: 
+      gcc_assert (0);  
+    }
+}
+
 /* After all options at LOC have been read into OPTS and OPTS_SET,
    finalize settings of those options and diagnose incompatible
    combinations.  */
@@ -1040,6 +1098,10 @@ finish_options (struct gcc_options *opts, struct gcc_options *opts_set,
   if ((opts->x_flag_sanitize & SANITIZE_KERNEL_ADDRESS) && opts->x_flag_tm)
     sorry ("transactional memory is not supported with "
 	   "%<-fsanitize=kernel-address%>");
+
+  /* Currently live patching is not support for LTO.  */
+  if (opts->x_flag_live_patching && in_lto_p) 
+    sorry ("live patching is not supported with LTO");
 }
 
 #define LEFT_COLUMN	27
@@ -2266,6 +2328,12 @@ common_handle_option (struct gcc_options *opts,
 	(&opts->x_flag_instrument_functions_exclude_files, arg);
       break;
 
+    case OPT_flive_patching_:
+      if (value)
+    	control_optimizations_for_live_patching (opts, opts_set,
+						 opts->x_flag_live_patching);
+      break;
+
     case OPT_fmessage_length_:
       pp_set_line_maximum_length (dc->printer, value);
       diagnostic_set_caret_max_width (dc, value);
diff --git a/gcc/testsuite/gcc.dg/live-patching-1.c b/gcc/testsuite/gcc.dg/live-patching-1.c
new file mode 100644
index 0000000..6a1ea38
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/live-patching-1.c
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -flive-patching=inline-only-static -fdump-ipa-inline" } */
+
+extern int sum, n, m;
+
+int foo (int a)
+{
+  return a + n;
+}
+
+static int bar (int b)
+{
+  return b * m;
+}
+
+int main()
+{
+  sum = foo (m) + bar (n); 
+  return 0;
+}
+
+/* { dg-final { scan-ipa-dump "foo/0 function has external linkage when the user requests only inlining static for live patching"  "inline" } } */
-- 
1.9.1

[-- Attachment #3: Type: text/plain, Size: 27 bytes --]



> 
> Thanks,
> Miroslav

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

[Martin Liška]

On 11/13/18 10:16 PM, Qing Zhao wrote:
> Hi,
> 
>> On Nov 13, 2018, at 1:18 PM, Miroslav Benes <mbenes@suse.cz> 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 multiple-level control on how many of the
>>>     optimizations are enabled by users' request.  The LEVEL argument
>>>     should be one of the following:
>>>
>>>     'inline-only-static'
>>>
>>>          Only enable inlining of static functions, disable all other
>>>          ipa optimizations/analyses.  As a result, when patching a
>>>          static routine, all its callers need to be patches as well.
>>>
>>>     'inline-clone'
>>>
>>>          Only enable inlining and all optimizations that internally
>>>          create clone, for example, cloning, ipa-sra, partial inlining,
>>>          etc.; disable all other ipa optimizations/analyses.  As a
>>>          result, when patching a routine, all its callers and its
>>>          clones' callers need to be patched as well.
>> Based on our previous discussion I assume that "clone" optimizations are 
>> safe (for LP) and the others are not. Anyway I'd welcome a note mentioning 
>> that disabled optimizations are dangerous for LP.
> actually, I don’t think that those disabled optimizations are “dangerous” for live-patching. one of the major reasons we disable them
> is because that currently the compiler does NOT provide a good way to compute the impacted function list for those optimizations.
> therefore, we disable them at this time. 
> 
> many of them could be enabled too if the compiler can report the impacted function list accurately in the future.
> 
> 
> 
>> I know it may be the same for you, but it is not for me as a GCC user. 
>> "internally create clone" sounds very... well, internal. It does not 
>> describe the option much for ordinary user whow has no knowledge about GCC 
>> internals.
>>
>> So could you rephrase it a bit, please?
> I tried to make this clear. please see the following:
> 
> '-flive-patching=LEVEL'
>      Control GCC's optimizations to provide a safe compilation for
>      live-patching.
> 
>      If the compiler's optimization uses a function's body or
>      information extracted from its body to optimize/change another
>      function, the latter is called an impacted function of the former.
>      If a function is patched, its impacted functions should be patched
>      too.
> 
>      The impacted functions are decided by the compiler's
>      interprocedural optimizations.  For example, inlining a function
>      into its caller, cloning a function and changing its caller to call
>      this new clone, or extracting a function's pureness/constness
>      information to optimize its direct or indirect callers, etc.
> 
>      Usually, the more ipa optimizations enabled, the larger the number
>      of impacted functions for each function.  In order to control the
>      number of impacted functions and computed the list of impacted
>      function easily, we provide control to partially enable ipa
>      optimizations on two different levels.
> 
>      The LEVEL argument should be one of the following:
> 
>      'inline-only-static'
> 
>           Only enable inlining of static functions, disable all other
>           interprocedural optimizations/analyses.  As a result, when
>           patching a static routine, all its callers need to be patches
>           as well.
> 
>      'inline-clone'
> 
>           Only enable inlining and cloning optimizations, which includes
>           inlining, cloning, interprocedural scalar replacement of
>           aggregates and partial inlining.  Disable all other
>           interprocedural optimizations/analyses.  As a result, when
>           patching a routine, all its callers and its clones' callers
>           need to be patched as well.
> 
>      When -flive-patching specified without any value, the default value
>      is "inline-clone".
> 
>      This flag is disabled by default.
> 
> 
>>>     When -flive-patching specified without any value, the default value
>>>     is "inline-clone".
>>>
>>>     This flag is disabled by default.
>>>
>>> let me know your comments and suggestions on the implementation.
>> I compared it to Martin's patch and ipa-icf-variables is not covered in 
>> yours (I may have missed something).
> Yes, you are right. I added this into my patch.
> 
> I am attaching the new patch here.

Hello.

Please use
git diff HEAD~ > /tmp/patch && ~/Programming/gcc/contrib/check_GNU_style.py /tmp/patch

in order to address many formatting issues of the patch (skip the ones reported in common.opt).

> 
> 
> flive-patching.patch
> 
> From c0785675eb29599754aaf11c70901c12dd3ea821 Mon Sep 17 00:00:00 2001
> From: qing zhao <qing.zhao@oracle.com>
> Date: Tue, 13 Nov 2018 13:02:57 -0800
> Subject: [PATCH] Add -flive-patching to support live patching
> 
> ---
>  gcc/cif-code.def                       |  6 +++
>  gcc/common.opt                         | 18 +++++++++
>  gcc/doc/invoke.texi                    | 49 +++++++++++++++++++++++-
>  gcc/flag-types.h                       |  8 ++++
>  gcc/ipa-inline.c                       |  6 +++
>  gcc/opts.c                             | 68 ++++++++++++++++++++++++++++++++++
>  gcc/testsuite/gcc.dg/live-patching-1.c | 22 +++++++++++
>  7 files changed, 176 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/gcc.dg/live-patching-1.c
> 
> diff --git a/gcc/cif-code.def b/gcc/cif-code.def
> index 19a7621..dffe15f 100644
> --- a/gcc/cif-code.def
> +++ b/gcc/cif-code.def
> @@ -132,6 +132,12 @@ DEFCIFCODE(USES_COMDAT_LOCAL, CIF_FINAL_ERROR,
>  DEFCIFCODE(ATTRIBUTE_MISMATCH, CIF_FINAL_ERROR,
>  	   N_("function attribute mismatch"))
>  
> +/* We can't inline because the user requests only static functions 
> +   but the function has external linkage for live patching purpose.  */
> +DEFCIFCODE(EXTERN_LIVE_ONLY_STATIC, CIF_FINAL_ERROR,
> +	   N_("function has external linkage when the user requests only"
> +	      " inlining static for live patching"))
> +
>  /* We proved that the call is unreachable.  */
>  DEFCIFCODE(UNREACHABLE, CIF_FINAL_ERROR,
>  	   N_("unreachable"))
> diff --git a/gcc/common.opt b/gcc/common.opt
> index 98e8eb0..346a361 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -2152,6 +2152,24 @@ starts and when the destructor finishes.
>  flifetime-dse=
>  Common Joined RejectNegative UInteger Var(flag_lifetime_dse) Optimization IntegerRange(0, 2)
>  
> +flive-patching
> +Common RejectNegative Alias(flive-patching=,inline-clone) Optimization
> +
> +flive-patching=
> +Common Report Joined RejectNegative Enum(live_patching_level) Var(flag_live_patching) Init(LIVE_NONE) Optimization
> +-flive-patching=[inline-only-static|inline-clone]	Control ipa optimizations to provide a 

Please use 'IPA' instead of 'ipa', similarly in documentation.

> +safe compilation for live-patching. At the same time, provides multiple-level control on the  
> +enabled optimizations. 
> +
> +Enum
> +Name(live_patching_level) Type(enum live_patching_level) UnknownError(unknown Live-Patching Level %qs)
> +
> +EnumValue
> +Enum(live_patching_level) String(inline-only-static) Value(LIVE_INLINE_ONLY_STATIC)
> +
> +EnumValue
> +Enum(live_patching_level) String(inline-clone) Value(LIVE_INLINE_CLONE)
> +
>  flive-range-shrinkage
>  Common Report Var(flag_live_range_shrinkage) Init(0) Optimization
>  Relief of register pressure through live range shrinkage.
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 4ea93a7..c473049 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -411,10 +411,11 @@ Objective-C and Objective-C++ Dialects}.
>  -fgcse-sm  -fhoist-adjacent-loads  -fif-conversion @gol
>  -fif-conversion2  -findirect-inlining @gol
>  -finline-functions  -finline-functions-called-once  -finline-limit=@var{n} @gol
> --finline-small-functions  -fipa-cp  -fipa-cp-clone @gol
> +-finline-small-functions -fipa-cp  -fipa-cp-clone @gol

This changes is probably not intended.

>  -fipa-bit-cp -fipa-vrp @gol
>  -fipa-pta  -fipa-profile  -fipa-pure-const  -fipa-reference  -fipa-reference-addressable @gol
>  -fipa-stack-alignment  -fipa-icf  -fira-algorithm=@var{algorithm} @gol
> +-flive-patching=@var{level} @gol
>  -fira-region=@var{region}  -fira-hoist-pressure @gol
>  -fira-loop-pressure  -fno-ira-share-save-slots @gol
>  -fno-ira-share-spill-slots @gol
> @@ -8982,6 +8983,52 @@ equivalences that are found only by GCC and equivalences found only by Gold.
>  
>  This flag is enabled by default at @option{-O2} and @option{-Os}.
>  
> +@item -flive-patching=@var{level}
> +@opindex flive-patching
> +Control GCC's optimizations to provide a safe compilation for live-patching.
> +
> +If the compiler's optimization uses a function's body or information extracted 
> +from its body to optimize/change another function, the latter is called an
> +impacted function of the former.  If a function is patched, its impacted
> +functions should be patched too.
> +
> +The impacted functions are decided by the compiler's interprocedural
> +optimizations. For example, inlining a function into its caller, cloning 
> +a function and changing its caller to call this new clone, or extracting
> +a function's pureness/constness information to optimize its direct or 
> +indirect callers, etc.
> +
> +Usually, the more ipa optimizations enabled, the larger the number of
> +impacted functions for each function. In order to control the number of
> +impacted functions and computed the list of impacted function easily, 
> +we provide control to partially enable ipa optimizations on two different 
> +levels.
> +
> +The @var{level} argument should be one of the following:
> +
> +@table @samp
> +
> +@item inline-only-static
> +
> +Only enable inlining of static functions, disable all other interprocedural 
> +optimizations/analyses. As a result, when patching a static routine,
> +all its callers need to be patches as well.
> +
> +@item inline-clone 
> +
> +Only enable inlining and cloning optimizations, which includes inlining, 
> +cloning, interprocedural scalar replacement of aggregates and partial inlining.
> +Disable all other interprocedural optimizations/analyses.
> +As a result, when patching a routine, all its callers and its clones'
> +callers need to be patched as well.
> +
> +@end table
> +
> +When -flive-patching specified without any value, the default value
> +is "inline-clone".
> +
> +This flag is disabled by default.
> +
>  @item -fisolate-erroneous-paths-dereference
>  @opindex fisolate-erroneous-paths-dereference
>  Detect paths that trigger erroneous or undefined behavior due to
> diff --git a/gcc/flag-types.h b/gcc/flag-types.h
> index 500f663..72e0f0f 100644
> --- a/gcc/flag-types.h
> +++ b/gcc/flag-types.h
> @@ -123,6 +123,14 @@ enum stack_reuse_level
>    SR_ALL
>  };
>  
> +/* The live patching level. */
> +enum live_patching_level
> +{
> +  LIVE_NONE = 0,
> +  LIVE_INLINE_ONLY_STATIC,
> +  LIVE_INLINE_CLONE

Maybe better LIVE_PATCHING_INLINE_CLONE, without the 'PATCHING' the enum
values are bit unclear.

> +};
> +
>  /* The algorithm used for basic block reordering.  */
>  enum reorder_blocks_algorithm
>  {
> diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
> index e04ede7..fadb437 100644
> --- a/gcc/ipa-inline.c
> +++ b/gcc/ipa-inline.c
> @@ -377,6 +377,12 @@ can_inline_edge_p (struct cgraph_edge *e, bool report,
>        e->inline_failed = CIF_ATTRIBUTE_MISMATCH;
>        inlinable = false;
>      }
> +  else if (callee->externally_visible 
> +	   && flag_live_patching == LIVE_INLINE_ONLY_STATIC) 
> +    {
> +      e->inline_failed = CIF_EXTERN_LIVE_ONLY_STATIC;
> +      inlinable = false;
> +    }
>    if (!inlinable && report)
>      report_inline_failed_reason (e);
>    return inlinable;
> diff --git a/gcc/opts.c b/gcc/opts.c
> index e21967b..281f9f4 100644
> --- a/gcc/opts.c
> +++ b/gcc/opts.c
> @@ -691,6 +691,64 @@ default_options_optimization (struct gcc_options *opts,
>  			 lang_mask, handlers, loc, dc);
>  }
>  
> +/* Control ipa optimizations based on different live patching LEVEL */
> +static void
> +control_optimizations_for_live_patching (struct gcc_options *opts, 
> +					 struct gcc_options *opts_set, 
> +					 enum live_patching_level level)
> +{
> +  gcc_assert (level > LIVE_NONE);
> +
> +  switch (level)
> +    {
> +    case LIVE_INLINE_ONLY_STATIC:
> +      if (!opts_set->x_flag_ipa_cp_clone)
> +        opts->x_flag_ipa_cp_clone = 0;      
> +      if (!opts_set->x_flag_ipa_sra)
> +        opts->x_flag_ipa_sra = 0;
> +      if (!opts_set->x_flag_partial_inlining)
> +        opts->x_flag_partial_inlining = 0;
> +      if (!opts_set->x_flag_ipa_cp)
> +        opts->x_flag_ipa_cp = 0;      
> +      /* FALLTHROUGH */
> +    case LIVE_INLINE_CLONE:
> +      /* live patching should disable whole-program optimization.  */
> +      if (!opts_set->x_flag_whole_program)
> +        opts->x_flag_whole_program = 0;
> +      /* visibility change should be excluded by !flag_whole_program 
> +	 && !in_lto_p && !flag_ipa_cp_clone && !flag_ipa_sra 

You added sorry about LTO, maybe then !in_lto_p would be always true?

> +	 && !flag_partial_inlining.  */
> +      if (!opts_set->x_flag_ipa_pta)
> +        opts->x_flag_ipa_pta = 0;
> +      if (!opts_set->x_flag_ipa_reference)
> +        opts->x_flag_ipa_reference = 0;
> +      if (!opts_set->x_flag_ipa_ra)
> +        opts->x_flag_ipa_ra = 0;
> +      if (!opts_set->x_flag_ipa_icf)
> +        opts->x_flag_ipa_icf = 0;
> +      if (!opts_set->x_flag_ipa_icf_functions)
> +        opts->x_flag_ipa_icf_functions = 0;
> +      if (!opts_set->x_flag_ipa_icf_variables)
> +        opts->x_flag_ipa_icf_variables = 0;
> +      if (!opts_set->x_flag_ipa_bit_cp)
> +        opts->x_flag_ipa_bit_cp = 0;
> +      if (!opts_set->x_flag_ipa_vrp)
> +        opts->x_flag_ipa_vrp = 0;
> +      if (!opts_set->x_flag_ipa_pure_const)

Can you please explain why you included:
      if (!opts_set->x_flag_ipa_bit_cp)
        opts->x_flag_ipa_bit_cp = 0;
      if (!opts_set->x_flag_ipa_vrp)
        opts->x_flag_ipa_vrp = 0;

?

> +        opts->x_flag_ipa_pure_const = 0;
> +      /* unreachable code removal.  */
> +      /* discovery of functions/variables with no address taken.  */

^^^ these 2 comments looks misaligned.

> +      if (!opts_set->x_flag_ipa_reference_addressable)
> +        opts->x_flag_ipa_reference_addressable = 0;
> +      /* ipa stack alignment propagation.  */
> +      if (!opts_set->x_flag_ipa_stack_alignment)
> +        opts->x_flag_ipa_stack_alignment = 0;
> +      break;
> +    default: 
> +      gcc_assert (0);  
> +    }
> +}
> +
>  /* After all options at LOC have been read into OPTS and OPTS_SET,
>     finalize settings of those options and diagnose incompatible
>     combinations.  */
> @@ -1040,6 +1098,10 @@ finish_options (struct gcc_options *opts, struct gcc_options *opts_set,
>    if ((opts->x_flag_sanitize & SANITIZE_KERNEL_ADDRESS) && opts->x_flag_tm)
>      sorry ("transactional memory is not supported with "
>  	   "%<-fsanitize=kernel-address%>");
> +
> +  /* Currently live patching is not support for LTO.  */
> +  if (opts->x_flag_live_patching && in_lto_p) 
> +    sorry ("live patching is not supported with LTO");
>  }
>  
>  #define LEFT_COLUMN	27
> @@ -2266,6 +2328,12 @@ common_handle_option (struct gcc_options *opts,
>  	(&opts->x_flag_instrument_functions_exclude_files, arg);
>        break;
>  
> +    case OPT_flive_patching_:
> +      if (value)
> +    	control_optimizations_for_live_patching (opts, opts_set,
> +						 opts->x_flag_live_patching);
> +      break;
> +
>      case OPT_fmessage_length_:
>        pp_set_line_maximum_length (dc->printer, value);
>        diagnostic_set_caret_max_width (dc, value);
> diff --git a/gcc/testsuite/gcc.dg/live-patching-1.c b/gcc/testsuite/gcc.dg/live-patching-1.c
> new file mode 100644
> index 0000000..6a1ea38
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/live-patching-1.c
> @@ -0,0 +1,22 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -flive-patching=inline-only-static -fdump-ipa-inline" } */
> +
> +extern int sum, n, m;
> +
> +int foo (int a)
> +{
> +  return a + n;
> +}
> +
> +static int bar (int b)
> +{
> +  return b * m;
> +}
> +
> +int main()
> +{
> +  sum = foo (m) + bar (n); 
> +  return 0;
> +}
> +
> +/* { dg-final { scan-ipa-dump "foo/0 function has external linkage when the user requests only inlining static for live patching"  "inline" } } */
> -- 1.9.1

It would be also handy to test the newly added option.
Please add ChangeLog entry for the patch. Have you bootstrapped the patch and run test-suite?

Thanks,
Martin

> 
> 
> 
>> Thanks,
>> Miroslav
> 

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

[Qing Zhao]

Hi, 


> On Nov 14, 2018, at 9:03 AM, Martin Liška <mliska@suse.cz> wrote:
> 
>>> 
>> Yes, you are right. I added this into my patch.
>> 
>> I am attaching the new patch here.
> 
> Hello.
> 
> Please use
> git diff HEAD~ > /tmp/patch && ~/Programming/gcc/contrib/check_GNU_style.py /tmp/patch
> 
> in order to address many formatting issues of the patch (skip the ones reported in common.opt).

will do and fix the style issues.

> 
>> 
>> 
>> +flive-patching
>> +Common RejectNegative Alias(flive-patching=,inline-clone) Optimization
>> +
>> +flive-patching=
>> +Common Report Joined RejectNegative Enum(live_patching_level) Var(flag_live_patching) Init(LIVE_NONE) Optimization
>> +-flive-patching=[inline-only-static|inline-clone]	Control ipa optimizations to provide a 
> 
> Please use 'IPA' instead of 'ipa', similarly in documentation.
Okay.
> 
>> --- a/gcc/doc/invoke.texi
>> +++ b/gcc/doc/invoke.texi
>> @@ -411,10 +411,11 @@ Objective-C and Objective-C++ Dialects}.
>> -fgcse-sm  -fhoist-adjacent-loads  -fif-conversion @gol
>> -fif-conversion2  -findirect-inlining @gol
>> -finline-functions  -finline-functions-called-once  -finline-limit=@var{n} @gol
>> --finline-small-functions  -fipa-cp  -fipa-cp-clone @gol
>> +-finline-small-functions -fipa-cp  -fipa-cp-clone @gol
> 
> This changes is probably not intended.
No. will delete it.

> 
>> 
>> diff --git a/gcc/flag-types.h b/gcc/flag-types.h
>> index 500f663..72e0f0f 100644
>> --- a/gcc/flag-types.h
>> +++ b/gcc/flag-types.h
>> @@ -123,6 +123,14 @@ enum stack_reuse_level
>>   SR_ALL
>> };
>> 
>> +/* The live patching level. */
>> +enum live_patching_level
>> +{
>> +  LIVE_NONE = 0,
>> +  LIVE_INLINE_ONLY_STATIC,
>> +  LIVE_INLINE_CLONE
> 
> Maybe better LIVE_PATCHING_INLINE_CLONE, without the 'PATCHING' the enum
> values are bit unclear.

Okay.
> 
>> 
>> +      /* visibility change should be excluded by !flag_whole_program 
>> +	 && !in_lto_p && !flag_ipa_cp_clone && !flag_ipa_sra 
> 
> You added sorry about LTO, maybe then !in_lto_p would be always true?

Yes, since live-patching does not support LTO currently,  !in_lto_p is always TRUE. that’s the reason no need for a new flag to disable visibility change. 
> 
>> +	 && !flag_partial_inlining.  */
>> +      if (!opts_set->x_flag_ipa_pta)
>> +        opts->x_flag_ipa_pta = 0;
>> +      if (!opts_set->x_flag_ipa_reference)
>> +        opts->x_flag_ipa_reference = 0;
>> +      if (!opts_set->x_flag_ipa_ra)
>> +        opts->x_flag_ipa_ra = 0;
>> +      if (!opts_set->x_flag_ipa_icf)
>> +        opts->x_flag_ipa_icf = 0;
>> +      if (!opts_set->x_flag_ipa_icf_functions)
>> +        opts->x_flag_ipa_icf_functions = 0;
>> +      if (!opts_set->x_flag_ipa_icf_variables)
>> +        opts->x_flag_ipa_icf_variables = 0;
>> +      if (!opts_set->x_flag_ipa_bit_cp)
>> +        opts->x_flag_ipa_bit_cp = 0;
>> +      if (!opts_set->x_flag_ipa_vrp)
>> +        opts->x_flag_ipa_vrp = 0;
>> +      if (!opts_set->x_flag_ipa_pure_const)
> 
> Can you please explain why you included:
>      if (!opts_set->x_flag_ipa_bit_cp)
>        opts->x_flag_ipa_bit_cp = 0;
>      if (!opts_set->x_flag_ipa_vrp)
>        opts->x_flag_ipa_vrp = 0;

interprocedural bitwise constant propagation and interprocedural propagation of value ranges does not involve creating clones,
and the bitwise constant and value ranges info extracted during ipa-cp phase are used later by other optimizations. their effect on 
impact functions are not clear at this moment. that’s the reason I think we need to disable these two. 

Martin Jambor raised this issue during our previous discussion on 10/03/2018:
“
I was thinking a bit more about this and recalled that not all stuff
that IPA-CP nowadays does involves creating clones, so we have to add
also:
 - -fno-ipa-bit-cp, and
 - -fno-ipa-vrp.

These two just record info in the parameters of *callees* of functions
from which it extracted info, without any cloning involved.  Both were
introduced in GCC 7.

Thanks,

Martin
“
and I think he is right.



> ?
> 
>> +        opts->x_flag_ipa_pure_const = 0;
>> +      /* unreachable code removal.  */
>> +      /* discovery of functions/variables with no address taken.  */
> 
> ^^^ these 2 comments looks misaligned.

will fix them. 
> 
>> 
>> +++ b/gcc/testsuite/gcc.dg/live-patching-1.c
>> @@ -0,0 +1,22 @@
>> +/* { dg-do compile } */
>> +/* { dg-options "-O2 -flive-patching=inline-only-static -fdump-ipa-inline" } */
>> +
>> +extern int sum, n, m;
>> +
>> +int foo (int a)
>> +{
>> +  return a + n;
>> +}
>> +
>> +static int bar (int b)
>> +{
>> +  return b * m;
>> +}
>> +
>> +int main()
>> +{
>> +  sum = foo (m) + bar (n); 
>> +  return 0;
>> +}
>> +
>> +/* { dg-final { scan-ipa-dump "foo/0 function has external linkage when the user requests only inlining static for live patching"  "inline" } } */
>> -- 1.9.1
> 
> It would be also handy to test the newly added option.

not sure how to test it? any suggestion?

> Please add ChangeLog entry for the patch.

Okay.

> Have you bootstrapped the patch and run test-suite?
did on aarch64. I will do it on x86_64 as well.

thanks.

Qing

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

[Martin Liška]

On 11/14/18 6:54 PM, Qing Zhao wrote:
> Hi, 
> 
> 
>> On Nov 14, 2018, at 9:03 AM, Martin Liška <mliska@suse.cz> wrote:
>>
>>>>
>>> Yes, you are right. I added this into my patch.
>>>
>>> I am attaching the new patch here.
>>
>> Hello.
>>
>> Please use
>> git diff HEAD~ > /tmp/patch && ~/Programming/gcc/contrib/check_GNU_style.py /tmp/patch
>>
>> in order to address many formatting issues of the patch (skip the ones reported in common.opt).
> 
> will do and fix the style issues.
> 
>>
>>>
>>>
>>> +flive-patching
>>> +Common RejectNegative Alias(flive-patching=,inline-clone) Optimization
>>> +
>>> +flive-patching=
>>> +Common Report Joined RejectNegative Enum(live_patching_level) Var(flag_live_patching) Init(LIVE_NONE) Optimization
>>> +-flive-patching=[inline-only-static|inline-clone]	Control ipa optimizations to provide a 
>>
>> Please use 'IPA' instead of 'ipa', similarly in documentation.
> Okay.
>>
>>> --- a/gcc/doc/invoke.texi
>>> +++ b/gcc/doc/invoke.texi
>>> @@ -411,10 +411,11 @@ Objective-C and Objective-C++ Dialects}.
>>> -fgcse-sm  -fhoist-adjacent-loads  -fif-conversion @gol
>>> -fif-conversion2  -findirect-inlining @gol
>>> -finline-functions  -finline-functions-called-once  -finline-limit=@var{n} @gol
>>> --finline-small-functions  -fipa-cp  -fipa-cp-clone @gol
>>> +-finline-small-functions -fipa-cp  -fipa-cp-clone @gol
>>
>> This changes is probably not intended.
> No. will delete it.
> 
>>
>>>
>>> diff --git a/gcc/flag-types.h b/gcc/flag-types.h
>>> index 500f663..72e0f0f 100644
>>> --- a/gcc/flag-types.h
>>> +++ b/gcc/flag-types.h
>>> @@ -123,6 +123,14 @@ enum stack_reuse_level
>>>   SR_ALL
>>> };
>>>
>>> +/* The live patching level. */
>>> +enum live_patching_level
>>> +{
>>> +  LIVE_NONE = 0,
>>> +  LIVE_INLINE_ONLY_STATIC,
>>> +  LIVE_INLINE_CLONE
>>
>> Maybe better LIVE_PATCHING_INLINE_CLONE, without the 'PATCHING' the enum
>> values are bit unclear.
> 
> Okay.
>>
>>>
>>> +      /* visibility change should be excluded by !flag_whole_program 
>>> +	 && !in_lto_p && !flag_ipa_cp_clone && !flag_ipa_sra 
>>
>> You added sorry about LTO, maybe then !in_lto_p would be always true?
> 
> Yes, since live-patching does not support LTO currently,  !in_lto_p is always TRUE. that’s the reason no need for a new flag to disable visibility change. 

Hi.

Ok.

>>
>>> +	 && !flag_partial_inlining.  */
>>> +      if (!opts_set->x_flag_ipa_pta)
>>> +        opts->x_flag_ipa_pta = 0;
>>> +      if (!opts_set->x_flag_ipa_reference)
>>> +        opts->x_flag_ipa_reference = 0;
>>> +      if (!opts_set->x_flag_ipa_ra)
>>> +        opts->x_flag_ipa_ra = 0;
>>> +      if (!opts_set->x_flag_ipa_icf)
>>> +        opts->x_flag_ipa_icf = 0;
>>> +      if (!opts_set->x_flag_ipa_icf_functions)
>>> +        opts->x_flag_ipa_icf_functions = 0;
>>> +      if (!opts_set->x_flag_ipa_icf_variables)
>>> +        opts->x_flag_ipa_icf_variables = 0;
>>> +      if (!opts_set->x_flag_ipa_bit_cp)
>>> +        opts->x_flag_ipa_bit_cp = 0;
>>> +      if (!opts_set->x_flag_ipa_vrp)
>>> +        opts->x_flag_ipa_vrp = 0;
>>> +      if (!opts_set->x_flag_ipa_pure_const)
>>
>> Can you please explain why you included:
>>      if (!opts_set->x_flag_ipa_bit_cp)
>>        opts->x_flag_ipa_bit_cp = 0;
>>      if (!opts_set->x_flag_ipa_vrp)
>>        opts->x_flag_ipa_vrp = 0;
> 
> interprocedural bitwise constant propagation and interprocedural propagation of value ranges does not involve creating clones,
> and the bitwise constant and value ranges info extracted during ipa-cp phase are used later by other optimizations. their effect on 
> impact functions are not clear at this moment. that’s the reason I think we need to disable these two. 
> 
> Martin Jambor raised this issue during our previous discussion on 10/03/2018:
> “
> I was thinking a bit more about this and recalled that not all stuff
> that IPA-CP nowadays does involves creating clones, so we have to add
> also:
>  - -fno-ipa-bit-cp, and
>  - -fno-ipa-vrp.
> 
> These two just record info in the parameters of *callees* of functions
> from which it extracted info, without any cloning involved.  Both were
> introduced in GCC 7.
> 
> Thanks,
> 
> Martin
> “
> and I think he is right.

Great, thanks for clarification! I forgot about that.

And please can you mention in documentation which options are disabled with -flive-patching=*?
We usually do it, e.g. take a look at '-Os' option:

```
‘-Os’ disables the following optimization flags:
-falign-functions -falign-jumps -falign-loops
-falign-labels -freorder-blocks -freorder-blocks-algorithm=stc
-freorder-blocks-and-partition -fprefetch-loop-arrays
```

> 
> 
> 
>> ?
>>
>>> +        opts->x_flag_ipa_pure_const = 0;
>>> +      /* unreachable code removal.  */
>>> +      /* discovery of functions/variables with no address taken.  */
>>
>> ^^^ these 2 comments looks misaligned.
> 
> will fix them. 
>>
>>>
>>> +++ b/gcc/testsuite/gcc.dg/live-patching-1.c
>>> @@ -0,0 +1,22 @@
>>> +/* { dg-do compile } */
>>> +/* { dg-options "-O2 -flive-patching=inline-only-static -fdump-ipa-inline" } */
>>> +
>>> +extern int sum, n, m;
>>> +
>>> +int foo (int a)
>>> +{
>>> +  return a + n;
>>> +}
>>> +
>>> +static int bar (int b)
>>> +{
>>> +  return b * m;
>>> +}
>>> +
>>> +int main()
>>> +{
>>> +  sum = foo (m) + bar (n); 
>>> +  return 0;
>>> +}
>>> +
>>> +/* { dg-final { scan-ipa-dump "foo/0 function has external linkage when the user requests only inlining static for live patching"  "inline" } } */
>>> -- 1.9.1
>>
>> It would be also handy to test the newly added option.
> 
> not sure how to test it? any suggestion?

I would just e.g. copy test for recently added
gcc.target/i386/ipa-stack-alignment.c and replace the
option with corresponding -flive-patching option.

> 
>> Please add ChangeLog entry for the patch.
> 
> Okay.

That will help you to set up a skeleton:
./contrib/mklog /tmp/patch > /tmp/changelog

> 
>> Have you bootstrapped the patch and run test-suite?
> did on aarch64. I will do it on x86_64 as well.

Good, please mentioned that when sending a patch next time.

One more nit, please use gcc_unreachable instead of gcc_assert (0).

Thanks for working on that,
Martin

> 
> thanks.
> 
> Qing
> 

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

[Qing Zhao]

HI,

>>> 
>>> Can you please explain why you included:
>>>     if (!opts_set->x_flag_ipa_bit_cp)
>>>       opts->x_flag_ipa_bit_cp = 0;
>>>     if (!opts_set->x_flag_ipa_vrp)
>>>       opts->x_flag_ipa_vrp = 0;
>> 
>> interprocedural bitwise constant propagation and interprocedural propagation of value ranges does not involve creating clones,
>> and the bitwise constant and value ranges info extracted during ipa-cp phase are used later by other optimizations. their effect on 
>> impact functions are not clear at this moment. that’s the reason I think we need to disable these two. 
>> 
>> Martin Jambor raised this issue during our previous discussion on 10/03/2018:
>> “
>> I was thinking a bit more about this and recalled that not all stuff
>> that IPA-CP nowadays does involves creating clones, so we have to add
>> also:
>> - -fno-ipa-bit-cp, and
>> - -fno-ipa-vrp.
>> 
>> These two just record info in the parameters of *callees* of functions
>> from which it extracted info, without any cloning involved.  Both were
>> introduced in GCC 7.
>> 
>> Thanks,
>> 
>> Martin
>> “
>> and I think he is right.
> 
> Great, thanks for clarification! I forgot about that.
> 
> And please can you mention in documentation which options are disabled with -flive-patching=*?
> We usually do it, e.g. take a look at '-Os' option:
> 
> ```
> ‘-Os’ disables the following optimization flags:
> -falign-functions -falign-jumps -falign-loops
> -falign-labels -freorder-blocks -freorder-blocks-algorithm=stc
> -freorder-blocks-and-partition -fprefetch-loop-arrays
> ```
> 

will add this.

>> 
>> 
>>> 
>>> It would be also handy to test the newly added option.
>> 
>> not sure how to test it? any suggestion?
> 
> I would just e.g. copy test for recently added
> gcc.target/i386/ipa-stack-alignment.c and replace the
> option with corresponding -flive-patching option.

thanks for the suggestion. 
> 
>> 
>>> Please add ChangeLog entry for the patch.
>> 
>> Okay.
> 
> That will help you to set up a skeleton:
> ./contrib/mklog /tmp/patch > /tmp/changelog

thanks for the tip!

> 
>> 
>>> Have you bootstrapped the patch and run test-suite?
>> did on aarch64. I will do it on x86_64 as well.
> 
> Good, please mentioned that when sending a patch next time.
> 
> One more nit, please use gcc_unreachable instead of gcc_assert (0).

Okay.

thanks a lot for the help.

Qing

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

[Qing Zhao]

[-- Attachment #1: Type: text/plain, Size: 1042 bytes --]

Hi,

this is the new version of the patch.

I have bootstrapped it on both aarch64 and x86,  no regression.

please take a look.

Okay for commit?

thanks.

Qing

==================================

gcc/ChangeLog:

2018-11-15  qing zhao  <qing.zhao@oracle.com>

	* cif-code.def (EXTERN_LIVE_ONLY_STATIC): New CIF code.
	* common.opt: Add -flive-patching flag.
	* doc/invoke.texi: Document -flive-patching.
	* flag-types.h (enum live_patching_level): New enum.
	* ipa-inline.c (can_inline_edge_p): Disable external functions from
	inlining when flag_live_patching is LIVE_PATCHING_INLINE_ONLY_STATIC.
	* opts.c (control_optimizations_for_live_patching): New function.
	(finish_options): Make flag_live_patching incompatible with flag_lto.
	(common_handle_option): Handle flive-patching flag.

gcc/testsuite/ChangeLog:

2018-11-15  qing zhao  <qing.zhao@oracle.com>

	* gcc.dg/live-patching-1.c: New test.
	* gcc.dg/live-patching-2.c: New test.
	* gcc.dg/tree-ssa/writeonly-3.c: New test.
	* gcc.target/i386/ipa-stack-alignment-2.c: New test.


[-- Attachment #2: flive-patching.patch --]
[-- Type: application/octet-stream, Size: 13436 bytes --]

From a8d98c8be081ffde19cb4497aeb09d96e5b8b771 Mon Sep 17 00:00:00 2001
From: qing zhao <qing.zhao@oracle.com>
Date: Thu, 15 Nov 2018 12:53:32 -0800
Subject: [PATCH] Add a first class option -flive-patching

---
 gcc/cif-code.def                                   |  6 ++
 gcc/common.opt                                     | 18 ++++++
 gcc/doc/invoke.texi                                | 60 +++++++++++++++++++
 gcc/flag-types.h                                   |  8 +++
 gcc/ipa-inline.c                                   |  6 ++
 gcc/opts.c                                         | 69 ++++++++++++++++++++++
 gcc/testsuite/gcc.dg/live-patching-1.c             | 22 +++++++
 gcc/testsuite/gcc.dg/live-patching-2.c             |  9 +++
 gcc/testsuite/gcc.dg/tree-ssa/writeonly-3.c        | 20 +++++++
 .../gcc.target/i386/ipa-stack-alignment-2.c        | 13 ++++
 10 files changed, 231 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/live-patching-1.c
 create mode 100644 gcc/testsuite/gcc.dg/live-patching-2.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/writeonly-3.c
 create mode 100644 gcc/testsuite/gcc.target/i386/ipa-stack-alignment-2.c

diff --git a/gcc/cif-code.def b/gcc/cif-code.def
index 19a7621..ac3f73c 100644
--- a/gcc/cif-code.def
+++ b/gcc/cif-code.def
@@ -132,6 +132,12 @@ DEFCIFCODE(USES_COMDAT_LOCAL, CIF_FINAL_ERROR,
 DEFCIFCODE(ATTRIBUTE_MISMATCH, CIF_FINAL_ERROR,
 	   N_("function attribute mismatch"))
 
+/* We can't inline because the user requests only static functions
+   but the function has external linkage for live patching purpose.  */
+DEFCIFCODE(EXTERN_LIVE_ONLY_STATIC, CIF_FINAL_ERROR,
+	   N_("function has external linkage when the user requests only"
+	      " inlining static for live patching"))
+
 /* We proved that the call is unreachable.  */
 DEFCIFCODE(UNREACHABLE, CIF_FINAL_ERROR,
 	   N_("unreachable"))
diff --git a/gcc/common.opt b/gcc/common.opt
index 73065f5..0e4218b 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2164,6 +2164,24 @@ starts and when the destructor finishes.
 flifetime-dse=
 Common Joined RejectNegative UInteger Var(flag_lifetime_dse) Optimization IntegerRange(0, 2)
 
+flive-patching
+Common RejectNegative Alias(flive-patching=,inline-clone) Optimization
+
+flive-patching=
+Common Report Joined RejectNegative Enum(live_patching_level) Var(flag_live_patching) Init(LIVE_PATCHING_NONE) Optimization
+-flive-patching=[inline-only-static|inline-clone]	Control IPA
+optimizations to provide a safe compilation for live-patching. At the same
+time, provides multiple-level control on the enabled IPA optimizations.
+
+Enum
+Name(live_patching_level) Type(enum live_patching_level) UnknownError(unknown Live-Patching Level %qs)
+
+EnumValue
+Enum(live_patching_level) String(inline-only-static) Value(LIVE_PATCHING_INLINE_ONLY_STATIC)
+
+EnumValue
+Enum(live_patching_level) String(inline-clone) Value(LIVE_PATCHING_INLINE_CLONE)
+
 flive-range-shrinkage
 Common Report Var(flag_live_range_shrinkage) Init(0) Optimization
 Relief of register pressure through live range shrinkage.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 283d20f..6719bd6 100644
--- 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  -fipa-reference  -fipa-reference-addressable @gol
 -fipa-stack-alignment  -fipa-icf  -fira-algorithm=@var{algorithm} @gol
+-flive-patching=@var{level} @gol
 -fira-region=@var{region}  -fira-hoist-pressure @gol
 -fira-loop-pressure  -fno-ira-share-save-slots @gol
 -fno-ira-share-spill-slots @gol
@@ -9045,6 +9046,65 @@ equivalences that are found only by GCC and equivalences found only by Gold.
 
 This flag is enabled by default at @option{-O2} and @option{-Os}.
 
+@item -flive-patching=@var{level}
+@opindex flive-patching
+Control GCC's optimizations to provide a safe compilation for live-patching.
+
+If the compiler's optimization uses a function's body or information extracted
+from its body to optimize/change another function, the latter is called an
+impacted function of the former.  If a function is patched, its impacted
+functions should be patched too.
+
+The impacted functions are decided by the compiler's interprocedural
+optimizations. For example, inlining a function into its caller, cloning
+a function and changing its caller to call this new clone, or extracting
+a function's pureness/constness information to optimize its direct or
+indirect callers, etc.
+
+Usually, the more IPA optimizations enabled, the larger the number of
+impacted functions for each function. In order to control the number of
+impacted functions and computed the list of impacted function easily,
+we provide control to partially enable IPA optimizations on two different
+levels.
+
+The @var{level} argument should be one of the following:
+
+@table @samp
+
+@item inline-clone
+
+Only enable inlining and cloning optimizations, which includes inlining,
+cloning, interprocedural scalar replacement of aggregates and partial inlining.
+As a result, when patching a function, all its callers and its clones'
+callers need to be patched as well.
+
+@option{-flive-patching=inline-clone} disables the following optimization flags:
+@gccoptlist{-fwhole-program  -fipa-pta  -fipa-reference  -fipa-ra @gol
+-fipa-icf  -fipa-icf-functions  -fipa-icf-variables @gol
+-fipa-bit-cp  -fipa-vrp  -fipa-pure-const  -fipa-reference-addressable @gol
+-fipa-stack-alignment}
+
+@item inline-only-static
+
+Only enable inlining of static functions.
+As a result, when patching a static function, all its callers need to be
+patches as well.
+
+In addition to all the flags that -flive-patching=inline-clone disables,
+@option{-flive-patching=inline-only-static} disables the following additional
+optimization flags:
+@gccoptlist{-fipa-cp-clone  -fipa-sra  -fpartial-inlining  -fipa-cp}
+
+@end table
+
+When -flive-patching specified without any value, the default value
+is "inline-clone".
+
+This flag is disabled by default.
+
+Note that -flive-patching is not supported with link-time optimizer.
+(@option{-flto}).
+
 @item -fisolate-erroneous-paths-dereference
 @opindex fisolate-erroneous-paths-dereference
 Detect paths that trigger erroneous or undefined behavior due to
diff --git a/gcc/flag-types.h b/gcc/flag-types.h
index 500f663..2bbca65 100644
--- a/gcc/flag-types.h
+++ b/gcc/flag-types.h
@@ -123,6 +123,14 @@ enum stack_reuse_level
   SR_ALL
 };
 
+/* The live patching level.  */
+enum live_patching_level
+{
+  LIVE_PATCHING_NONE = 0,
+  LIVE_PATCHING_INLINE_ONLY_STATIC,
+  LIVE_PATCHING_INLINE_CLONE
+};
+
 /* The algorithm used for basic block reordering.  */
 enum reorder_blocks_algorithm
 {
diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
index 173808a..bd6ab22 100644
--- a/gcc/ipa-inline.c
+++ b/gcc/ipa-inline.c
@@ -379,6 +379,12 @@ can_inline_edge_p (struct cgraph_edge *e, bool report,
       e->inline_failed = CIF_ATTRIBUTE_MISMATCH;
       inlinable = false;
     }
+  else if (callee->externally_visible
+	   && flag_live_patching == LIVE_PATCHING_INLINE_ONLY_STATIC)
+    {
+      e->inline_failed = CIF_EXTERN_LIVE_ONLY_STATIC;
+      inlinable = false;
+    }
   if (!inlinable && report)
     report_inline_failed_reason (e);
   return inlinable;
diff --git a/gcc/opts.c b/gcc/opts.c
index e21967b..9d237c2 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -691,6 +691,65 @@ default_options_optimization (struct gcc_options *opts,
 			 lang_mask, handlers, loc, dc);
 }
 
+/* Control IPA optimizations based on different live patching LEVEL.  */
+static void
+control_optimizations_for_live_patching (struct gcc_options *opts,
+					 struct gcc_options *opts_set,
+					 enum live_patching_level level)
+{
+  gcc_assert (level > LIVE_PATCHING_NONE);
+
+  switch (level)
+    {
+    case LIVE_PATCHING_INLINE_ONLY_STATIC:
+      if (!opts_set->x_flag_ipa_cp_clone)
+	opts->x_flag_ipa_cp_clone = 0;
+      if (!opts_set->x_flag_ipa_sra)
+	opts->x_flag_ipa_sra = 0;
+      if (!opts_set->x_flag_partial_inlining)
+	opts->x_flag_partial_inlining = 0;
+      if (!opts_set->x_flag_ipa_cp)
+	opts->x_flag_ipa_cp = 0;
+      /* FALLTHROUGH.  */
+    case LIVE_PATCHING_INLINE_CLONE:
+      /* live patching should disable whole-program optimization.  */
+      if (!opts_set->x_flag_whole_program)
+	opts->x_flag_whole_program = 0;
+      /* visibility change should be excluded by !flag_whole_program
+	 && !in_lto_p && !flag_ipa_cp_clone && !flag_ipa_sra
+	 && !flag_partial_inlining.  */
+      if (!opts_set->x_flag_ipa_pta)
+	opts->x_flag_ipa_pta = 0;
+      if (!opts_set->x_flag_ipa_reference)
+	opts->x_flag_ipa_reference = 0;
+      if (!opts_set->x_flag_ipa_ra)
+	opts->x_flag_ipa_ra = 0;
+      if (!opts_set->x_flag_ipa_icf)
+	opts->x_flag_ipa_icf = 0;
+      if (!opts_set->x_flag_ipa_icf_functions)
+	opts->x_flag_ipa_icf_functions = 0;
+      if (!opts_set->x_flag_ipa_icf_variables)
+	opts->x_flag_ipa_icf_variables = 0;
+      if (!opts_set->x_flag_ipa_bit_cp)
+	opts->x_flag_ipa_bit_cp = 0;
+      if (!opts_set->x_flag_ipa_vrp)
+	opts->x_flag_ipa_vrp = 0;
+      if (!opts_set->x_flag_ipa_pure_const)
+	opts->x_flag_ipa_pure_const = 0;
+      /* FIXME: disable unreachable code removal.  */
+
+      /* discovery of functions/variables with no address taken.  */
+      if (!opts_set->x_flag_ipa_reference_addressable)
+	opts->x_flag_ipa_reference_addressable = 0;
+      /* ipa stack alignment propagation.  */
+      if (!opts_set->x_flag_ipa_stack_alignment)
+	opts->x_flag_ipa_stack_alignment = 0;
+      break;
+    default:
+      gcc_unreachable ();
+    }
+}
+
 /* After all options at LOC have been read into OPTS and OPTS_SET,
    finalize settings of those options and diagnose incompatible
    combinations.  */
@@ -1040,6 +1099,10 @@ finish_options (struct gcc_options *opts, struct gcc_options *opts_set,
   if ((opts->x_flag_sanitize & SANITIZE_KERNEL_ADDRESS) && opts->x_flag_tm)
     sorry ("transactional memory is not supported with "
 	   "%<-fsanitize=kernel-address%>");
+
+  /* Currently live patching is not support for LTO.  */
+  if (opts->x_flag_live_patching && opts->x_flag_lto)
+    sorry ("live patching is not supported with LTO");
 }
 
 #define LEFT_COLUMN	27
@@ -2266,6 +2329,12 @@ common_handle_option (struct gcc_options *opts,
 	(&opts->x_flag_instrument_functions_exclude_files, arg);
       break;
 
+    case OPT_flive_patching_:
+      if (value)
+    	control_optimizations_for_live_patching (opts, opts_set,
+						 opts->x_flag_live_patching);
+      break;
+
     case OPT_fmessage_length_:
       pp_set_line_maximum_length (dc->printer, value);
       diagnostic_set_caret_max_width (dc, value);
diff --git a/gcc/testsuite/gcc.dg/live-patching-1.c b/gcc/testsuite/gcc.dg/live-patching-1.c
new file mode 100644
index 0000000..6a1ea38
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/live-patching-1.c
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -flive-patching=inline-only-static -fdump-ipa-inline" } */
+
+extern int sum, n, m;
+
+int foo (int a)
+{
+  return a + n;
+}
+
+static int bar (int b)
+{
+  return b * m;
+}
+
+int main()
+{
+  sum = foo (m) + bar (n); 
+  return 0;
+}
+
+/* { dg-final { scan-ipa-dump "foo/0 function has external linkage when the user requests only inlining static for live patching"  "inline" } } */
diff --git a/gcc/testsuite/gcc.dg/live-patching-2.c b/gcc/testsuite/gcc.dg/live-patching-2.c
new file mode 100644
index 0000000..b418aaf
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/live-patching-2.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -flive-patching -flto" } */
+
+int main()
+{
+  return 0;
+}
+
+/* { dg-message "sorry, unimplemented: live patching is not supported with LTO" "-flive-patching and -flto together" { target *-*-* } 0 } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/writeonly-3.c b/gcc/testsuite/gcc.dg/tree-ssa/writeonly-3.c
new file mode 100644
index 0000000..4be4cf7
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/writeonly-3.c
@@ -0,0 +1,20 @@
+/* { dg-do compile } */
+/* { dg-options "-O1 -fdump-tree-optimized -flive-patching" } */
+static struct a {int magic1,b;} a;
+volatile int magic2;
+static struct b {int a,b,c,d,e,f;} magic3;
+
+struct b foo();
+
+void
+t()
+{
+ a.magic1 = 1;
+ magic2 = 1;
+ magic3 = foo();
+}
+/* { dg-final { scan-tree-dump "magic1" "optimized"} } */
+/* { dg-final { scan-tree-dump "magic3" "optimized"} } */
+/* { dg-final { scan-tree-dump "magic2" "optimized"} } */
+/* { dg-final { scan-tree-dump "foo" "optimized"} } */
+ 
diff --git a/gcc/testsuite/gcc.target/i386/ipa-stack-alignment-2.c b/gcc/testsuite/gcc.target/i386/ipa-stack-alignment-2.c
new file mode 100644
index 0000000..8ba7000
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/ipa-stack-alignment-2.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-flive-patching -O" } */
+
+typedef struct {
+  long a;
+  long b[];
+} c;
+
+c *d;
+void e() { d->b[0] = 5; }
+void f() { e(); }
+
+/* { dg-final { scan-assembler "sub.*%.sp" } } */
-- 
1.9.1

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

[Martin Liška]

[-- Attachment #1: Type: text/plain, Size: 1485 bytes --]

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.
> 
> please take a look.

Thanks for the updated version of the patch.
I have last small nits I see:

- gcc/common.opt: when running --help=common, the line is too long
- gcc/doc/invoke.texi - 2 spaces in between sentences + better gol
- gcc/opts.c - do not mix spaces + tabs

With that I'm fine. But note that I'm not a maintainer :)

Thanks,
Martin

> 
> Okay for commit?
> 
> thanks.
> 
> Qing
> 
> ==================================
> 
> gcc/ChangeLog:
> 
> 2018-11-15  qing zhao  <qing.zhao@oracle.com>
> 
> 	* cif-code.def (EXTERN_LIVE_ONLY_STATIC): New CIF code.
> 	* common.opt: Add -flive-patching flag.
> 	* doc/invoke.texi: Document -flive-patching.
> 	* flag-types.h (enum live_patching_level): New enum.
> 	* ipa-inline.c (can_inline_edge_p): Disable external functions from
> 	inlining when flag_live_patching is LIVE_PATCHING_INLINE_ONLY_STATIC.
> 	* opts.c (control_optimizations_for_live_patching): New function.
> 	(finish_options): Make flag_live_patching incompatible with flag_lto.
> 	(common_handle_option): Handle flive-patching flag.
> 
> gcc/testsuite/ChangeLog:
> 
> 2018-11-15  qing zhao  <qing.zhao@oracle.com>
> 
> 	* gcc.dg/live-patching-1.c: New test.
> 	* gcc.dg/live-patching-2.c: New test.
> 	* gcc.dg/tree-ssa/writeonly-3.c: New test.
> 	* gcc.target/i386/ipa-stack-alignment-2.c: New test.
> 

[-- Attachment #2: 0001-my-fixes.patch --]
[-- Type: text/x-patch, Size: 3020 bytes --]

From e44d8b88ac5fb712d5b5e7fdf2f2ad7f43b8ea09 Mon Sep 17 00:00:00 2001
From: marxin <mliska@suse.cz>
Date: Fri, 16 Nov 2018 16:23:44 +0100
Subject: [PATCH] my fixes.

---
 gcc/common.opt      | 3 +--
 gcc/doc/invoke.texi | 8 ++++----
 gcc/opts.c          | 2 +-
 3 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/gcc/common.opt b/gcc/common.opt
index 63cd6cc851d..35c24b8e8cf 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2187,8 +2187,7 @@ Common RejectNegative Alias(flive-patching=,inline-clone) Optimization
 flive-patching=
 Common Report Joined RejectNegative Enum(live_patching_level) Var(flag_live_patching) Init(LIVE_PATCHING_NONE) Optimization
 -flive-patching=[inline-only-static|inline-clone]	Control IPA
-optimizations to provide a safe compilation for live-patching. At the same
-time, provides multiple-level control on the enabled IPA optimizations.
+optimizations to provide a safe compilation for live-patching.
 
 Enum
 Name(live_patching_level) Type(enum live_patching_level) UnknownError(unknown Live-Patching Level %qs)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 0fb67163490..9cccc4455fa 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -9288,13 +9288,13 @@ impacted function of the former.  If a function is patched, its impacted
 functions should be patched too.
 
 The impacted functions are decided by the compiler's interprocedural
-optimizations. For example, inlining a function into its caller, cloning
+optimizations.  For example, inlining a function into its caller, cloning
 a function and changing its caller to call this new clone, or extracting
 a function's pureness/constness information to optimize its direct or
 indirect callers, etc.
 
 Usually, the more IPA optimizations enabled, the larger the number of
-impacted functions for each function. In order to control the number of
+impacted functions for each function.  In order to control the number of
 impacted functions and computed the list of impacted function easily,
 we provide control to partially enable IPA optimizations on two different
 levels.
@@ -9313,8 +9313,8 @@ callers need to be patched as well.
 @option{-flive-patching=inline-clone} disables the following optimization flags:
 @gccoptlist{-fwhole-program  -fipa-pta  -fipa-reference  -fipa-ra @gol
 -fipa-icf  -fipa-icf-functions  -fipa-icf-variables @gol
--fipa-bit-cp  -fipa-vrp  -fipa-pure-const  -fipa-reference-addressable @gol
--fipa-stack-alignment}
+-fipa-bit-cp  -fipa-vrp  -fipa-pure-const @gol
+-fipa-reference-addressable -fipa-stack-alignment}
 
 @item inline-only-static
 
diff --git a/gcc/opts.c b/gcc/opts.c
index 570155816e3..0b5e89faeee 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -2347,7 +2347,7 @@ common_handle_option (struct gcc_options *opts,
 
     case OPT_flive_patching_:
       if (value)
-    	control_optimizations_for_live_patching (opts, opts_set,
+	control_optimizations_for_live_patching (opts, opts_set,
 						 opts->x_flag_live_patching);
       break;
 
-- 
2.19.1

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

[Jan Hubicka]

> 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.
> > 
> > please take a look.
> 
> Thanks for the updated version of the patch.
> I have last small nits I see:
> 
> - gcc/common.opt: when running --help=common, the line is too long
> - gcc/doc/invoke.texi - 2 spaces in between sentences + better gol
> - gcc/opts.c - do not mix spaces + tabs
> 
> With that I'm fine. But note that I'm not a maintainer :)

I wonder what happens, when I pass like -flive-patching -fwhole-program
compared to -fwhole-program -flive-patching.
It seems to me that in first case we will end up with whole-program
optimization while in the second we won't.

I guess we should behave in a way that we disable the passes when
they are enabled implicitly (such as by -O2) but output an error when
once uses contradicting set of options, lie -flive-patching
-fwhole-program?

Honza
> 
> Thanks,
> Martin
> 
> > 
> > Okay for commit?
> > 
> > thanks.
> > 
> > Qing
> > 
> > ==================================
> > 
> > gcc/ChangeLog:
> > 
> > 2018-11-15  qing zhao  <qing.zhao@oracle.com>
> > 
> > 	* cif-code.def (EXTERN_LIVE_ONLY_STATIC): New CIF code.
> > 	* common.opt: Add -flive-patching flag.
> > 	* doc/invoke.texi: Document -flive-patching.
> > 	* flag-types.h (enum live_patching_level): New enum.
> > 	* ipa-inline.c (can_inline_edge_p): Disable external functions from
> > 	inlining when flag_live_patching is LIVE_PATCHING_INLINE_ONLY_STATIC.
> > 	* opts.c (control_optimizations_for_live_patching): New function.
> > 	(finish_options): Make flag_live_patching incompatible with flag_lto.
> > 	(common_handle_option): Handle flive-patching flag.
> > 
> > gcc/testsuite/ChangeLog:
> > 
> > 2018-11-15  qing zhao  <qing.zhao@oracle.com>
> > 
> > 	* gcc.dg/live-patching-1.c: New test.
> > 	* gcc.dg/live-patching-2.c: New test.
> > 	* gcc.dg/tree-ssa/writeonly-3.c: New test.
> > 	* gcc.target/i386/ipa-stack-alignment-2.c: New test.
> > 

> From e44d8b88ac5fb712d5b5e7fdf2f2ad7f43b8ea09 Mon Sep 17 00:00:00 2001
> From: marxin <mliska@suse.cz>
> Date: Fri, 16 Nov 2018 16:23:44 +0100
> Subject: [PATCH] my fixes.
> 
> ---
>  gcc/common.opt      | 3 +--
>  gcc/doc/invoke.texi | 8 ++++----
>  gcc/opts.c          | 2 +-
>  3 files changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/gcc/common.opt b/gcc/common.opt
> index 63cd6cc851d..35c24b8e8cf 100644
> --- a/gcc/common.opt
> +++ b/gcc/common.opt
> @@ -2187,8 +2187,7 @@ Common RejectNegative Alias(flive-patching=,inline-clone) Optimization
>  flive-patching=
>  Common Report Joined RejectNegative Enum(live_patching_level) Var(flag_live_patching) Init(LIVE_PATCHING_NONE) Optimization
>  -flive-patching=[inline-only-static|inline-clone]	Control IPA
> -optimizations to provide a safe compilation for live-patching. At the same
> -time, provides multiple-level control on the enabled IPA optimizations.
> +optimizations to provide a safe compilation for live-patching.
>  
>  Enum
>  Name(live_patching_level) Type(enum live_patching_level) UnknownError(unknown Live-Patching Level %qs)
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 0fb67163490..9cccc4455fa 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -9288,13 +9288,13 @@ impacted function of the former.  If a function is patched, its impacted
>  functions should be patched too.
>  
>  The impacted functions are decided by the compiler's interprocedural
> -optimizations. For example, inlining a function into its caller, cloning
> +optimizations.  For example, inlining a function into its caller, cloning
>  a function and changing its caller to call this new clone, or extracting
>  a function's pureness/constness information to optimize its direct or
>  indirect callers, etc.
>  
>  Usually, the more IPA optimizations enabled, the larger the number of
> -impacted functions for each function. In order to control the number of
> +impacted functions for each function.  In order to control the number of
>  impacted functions and computed the list of impacted function easily,
>  we provide control to partially enable IPA optimizations on two different
>  levels.
> @@ -9313,8 +9313,8 @@ callers need to be patched as well.
>  @option{-flive-patching=inline-clone} disables the following optimization flags:
>  @gccoptlist{-fwhole-program  -fipa-pta  -fipa-reference  -fipa-ra @gol
>  -fipa-icf  -fipa-icf-functions  -fipa-icf-variables @gol
> --fipa-bit-cp  -fipa-vrp  -fipa-pure-const  -fipa-reference-addressable @gol
> --fipa-stack-alignment}
> +-fipa-bit-cp  -fipa-vrp  -fipa-pure-const @gol
> +-fipa-reference-addressable -fipa-stack-alignment}
>  
>  @item inline-only-static
>  
> diff --git a/gcc/opts.c b/gcc/opts.c
> index 570155816e3..0b5e89faeee 100644
> --- a/gcc/opts.c
> +++ b/gcc/opts.c
> @@ -2347,7 +2347,7 @@ common_handle_option (struct gcc_options *opts,
>  
>      case OPT_flive_patching_:
>        if (value)
> -    	control_optimizations_for_live_patching (opts, opts_set,
> +	control_optimizations_for_live_patching (opts, opts_set,
>  						 opts->x_flag_live_patching);
>        break;
>  
> -- 
> 2.19.1
> 

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

[Qing Zhao]

> On Nov 16, 2018, at 9:51 AM, Jan Hubicka <hubicka@ucw.cz> 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.
>>> 
>>> please take a look.
>> 
>> Thanks for the updated version of the patch.
>> I have last small nits I see:
>> 
>> - gcc/common.opt: when running --help=common, the line is too long
>> - gcc/doc/invoke.texi - 2 spaces in between sentences + better gol
>> - gcc/opts.c - do not mix spaces + tabs
>> 
>> With that I'm fine. But note that I'm not a maintainer :)
> 
> I wonder what happens, when I pass like -flive-patching -fwhole-program
> compared to -fwhole-program -flive-patching.
> It seems to me that in first case we will end up with whole-program
> optimization while in the second we won't.
> 
> I guess we should behave in a way that we disable the passes when
> they are enabled implicitly (such as by -O2) but output an error when
> once uses contradicting set of options, lie -flive-patching
> -fwhole-program?

I have thought of this during the implementation, but finally I decided to provide the user 
an opportunity to explicitly enable an ipa optimization if they really want to, even though 
the -flive-patching disables that ipa optimization.   

But I am Okay to change to the behavior you described in the above, I think it’s reasonable too. 

Qing
> 
> Honza
>> 
>> Thanks,
>> Martin
>> 

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

[Qing Zhao]

> On Nov 16, 2018, at 9:26 AM, Martin Liška <mliska@suse.cz> 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.
>> 
>> please take a look.
> 
> Thanks for the updated version of the patch.
> I have last small nits I see:
> 
> - gcc/common.opt: when running --help=common, the line is too long

the following is the output for ./gcc —help=common:
  -flive-patching             Same as -flive-patching=.  Use the latter option
                              instead.
  -flive-patching=[inline-only-static|inline-clone] Control IPA optimizations
                              to provide a safe compilation for live-patching.
                              At the same time, provides multiple-level control
                              on the enabled IPA optimizations.
 
Not sure what’s you mean of “the line is too long”? could you please specify the above which line?

> - gcc/doc/invoke.texi - 2 spaces in between sentences + better gol
> - gcc/opts.c - do not mix spaces + tabs

I have used contrib/check_GNU_style.sh to check the patch, I did see one place that complains about 2 spaces in between sentences, fixed it.
but I didn’t see spaces + tabs mix issue with the script. could you please specify?

thanks.

Qing

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

[Martin Liška]

On 11/16/18 5:04 PM, Qing Zhao wrote:
> 
>> On Nov 16, 2018, at 9:26 AM, Martin Liška <mliska@suse.cz <mailto:mliska@suse.cz>> 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.
>>>
>>> please take a look.
>>
>> Thanks for the updated version of the patch.
>> I have last small nits I see:
>>
>> - gcc/common.opt: when running --help=common, the line is too long
> 
> the following is the output for ./gcc —help=common:
>   -flive-patching             Same as -flive-patching=.  Use the latter option
>                               instead.
>   -flive-patching=[inline-only-static|inline-clone] Control IPA optimizations
>                               to provide a safe compilation for live-patching.
>                               At the same time, provides multiple-level control
>                               on the enabled IPA optimizations.
>  
> Not sure what’s you mean of “the line is too long”? could you please specify the above which line?

You are probably using a console that has quite small column limit, so that you see it automatically
wrapped.

I see:

...
  -flimit-function-alignment  This option lacks documentation.
  -flive-patching             Same as -flive-patching=.  Use the latter option instead.
  -flive-patching=[inline-only-static|inline-clone] Control IPA optimizations to provide a safe compilation for live-patching. At the same time, provides multiple-level control on the enabled IPA optimizations.

^--- the long line

  -flive-range-shrinkage      Relief of register pressure through live range shrinkage.
  -floop-block                Enable loop nest transforms.  Same as -floop-nest-optimize.  Same as -floop-nest-optimize.
...

> 
>> - gcc/doc/invoke.texi - 2 spaces in between sentences + better gol
>> - gcc/opts.c - do not mix spaces + tabs
> 
> I have used contrib/check_GNU_style.sh to check the patch, I did see one place that complains about 2 spaces in between sentences, fixed it.

I see it:

=== ERROR type #3: dot, space, space, new sentence (3 error(s)) ===
gcc/common.opt:2190:62:optimizations to provide a safe compilation for live-patching.â–ˆAt the same
gcc/doc/invoke.texi:9291:14:optimizations.â–ˆFor example, inlining a function into its caller, cloning
gcc/doc/invoke.texi:9297:37:impacted functions for each function.â–ˆIn order to control the number of

> but I didn’t see spaces + tabs mix issue with the script. could you please specify?

This is a new check that I've just installed:

=== ERROR type #1: a space should not precede a tab (1 error(s)) ===
gcc/opts.c:2350:0:    ████████control_optimizations_for_live_patching (opts, opts_set,

Martin

> 
> thanks.
> 
> Qing
> *
> *
> 

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

[Qing Zhao]

> On Nov 19, 2018, at 2:11 AM, Martin Liška <mliska@suse.cz> wrote:
> 
> On 11/16/18 5:04 PM, Qing Zhao wrote:
>> 
>>> On Nov 16, 2018, at 9:26 AM, Martin Liška <mliska@suse.cz <mailto:mliska@suse.cz>> 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.
>>>> 
>>>> please take a look.
>>> 
>>> Thanks for the updated version of the patch.
>>> I have last small nits I see:
>>> 
>>> - gcc/common.opt: when running --help=common, the line is too long
>> 
>> the following is the output for ./gcc —help=common:
>>   -flive-patching             Same as -flive-patching=.  Use the latter option
>>                               instead.
>>   -flive-patching=[inline-only-static|inline-clone] Control IPA optimizations
>>                               to provide a safe compilation for live-patching.
>>                               At the same time, provides multiple-level control
>>                               on the enabled IPA optimizations.
>>  
>> Not sure what’s you mean of “the line is too long”? could you please specify the above which line?
> 
> You are probably using a console that has quite small column limit, so that you see it automatically
> wrapped.
> 
> I see:
> 
> ...
>  -flimit-function-alignment  This option lacks documentation.
>  -flive-patching             Same as -flive-patching=.  Use the latter option instead.
>  -flive-patching=[inline-only-static|inline-clone] Control IPA optimizations to provide a safe compilation for live-patching. At the same time, provides multiple-level control on the enabled IPA optimizations.
> 
> ^--- the long line

Okay, I see.

From the documentation: https://gcc.gnu.org/onlinedocs/gcc-4.3.4/gccint/Option-file-format.html#Option-file-format

"
An option definition record. �These records have the following fields:
	• the name of the option, with the leading “-” removed
	• a space-separated list of option properties (see Option properties)
	• the help text to use for --help (omitted if the second field contains the Undocumented property).
….
The help text is automatically line-wrapped before being displayed. Normally the name of the option is printed on the left-hand side of the output and the help text is printed on the right. However, if the help text contains a tab character, the text to the left of the tab is used instead of the option's name and the text to the right of the tab forms the help text. This allows you to elaborate on what type of argument the option takes.       
“

Looks like that by design, the help text will be automatically line-wrapped before being displayed to fit on the current console. So, I think that the long line should be fine? (the only way to
make the help text shorter line is to cut the help text). 

I also see some other options have even longer help text:

  -fcf-protection=[full|branch|return|none] Instrument functions with checks to verify jump/call/return control-flow transfer instructions have valid targets.
  -fisolate-erroneous-paths-attribute Detect paths that trigger erroneous or undefined behavior due to a null value being used in a way forbidden by a returns_nonnull or nonnull
                              attribute.  Isolate those paths from the main control flow and turn the statement with erroneous or undefined behavior into a trap.
  -fisolate-erroneous-paths-dereference Detect paths that trigger erroneous or undefined behavior due to dereferencing a null pointer.  Isolate those paths from the main control flow
                              and turn the statement with erroneous or undefined behavior into a trap.

> ...
> 
>> 
>>> - gcc/doc/invoke.texi - 2 spaces in between sentences + better gol
>>> - gcc/opts.c - do not mix spaces + tabs
>> 
>> I have used contrib/check_GNU_style.sh to check the patch, I did see one place that complains about 2 spaces in between sentences, fixed it.
> 
> I see it:
> 
> === ERROR type #3: dot, space, space, new sentence (3 error(s)) ===
> gcc/common.opt:2190:62:optimizations to provide a safe compilation for live-patching.█At the same
> gcc/doc/invoke.texi:9291:14:optimizations.█For example, inlining a function into its caller, cloning
> gcc/doc/invoke.texi:9297:37:impacted functions for each function.█In order to control the number of

fixed.

> 
>> but I didn’t see spaces + tabs mix issue with the script. could you please specify?
> 
> This is a new check that I've just installed:
> 
> === ERROR type #1: a space should not precede a tab (1 error(s)) ===
> gcc/opts.c:2350:0:    ████████control_optimizations_for_live_patching (opts, opts_set,

Okay, I see, fixed. 

thanks.

Qing
> 
> Martin
> 
>> 
>> thanks.
>> 
>> Qing
>> *
>> *

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

[Martin Liška]

On 11/19/18 4:52 PM, Qing Zhao wrote:
> 
>> On Nov 19, 2018, at 2:11 AM, Martin Liška <mliska@suse.cz <mailto:mliska@suse.cz>> wrote:
>>
>> On 11/16/18 5:04 PM, Qing Zhao wrote:
>>>
>>>> On Nov 16, 2018, at 9:26 AM, Martin Liška <mliska@suse.cz <mailto:mliska@suse.cz> <mailto:mliska@suse.cz>> 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.
>>>>>
>>>>> please take a look.
>>>>
>>>> Thanks for the updated version of the patch.
>>>> I have last small nits I see:
>>>>
>>>> - gcc/common.opt: when running --help=common, the line is too long
>>>
>>> the following is the output for ./gcc —help=common:
>>>   -flive-patching             Same as -flive-patching=.  Use the latter option
>>>                               instead.
>>>   -flive-patching=[inline-only-static|inline-clone] Control IPA optimizations
>>>                               to provide a safe compilation for live-patching.
>>>                               At the same time, provides multiple-level control
>>>                               on the enabled IPA optimizations.
>>>  
>>> Not sure what’s you mean of “the line is too long”? could you please specify the above which line?
>>
>> You are probably using a console that has quite small column limit, so that you see it automatically
>> wrapped.
>>
>> I see:
>>
>> ...
>>  -flimit-function-alignment  This option lacks documentation.
>>  -flive-patching             Same as -flive-patching=.  Use the latter option instead.
>>  -flive-patching=[inline-only-static|inline-clone] Control IPA optimizations to provide a safe compilation for live-patching. At the same time, provides multiple-level control on the enabled IPA optimizations.
>>
>> ^--- the long line
> 
> Okay, I see.
> 
> From the documentation: https://gcc.gnu.org/onlinedocs/gcc-4.3.4/gccint/Option-file-format.html#Option-file-format
> 
> "
> An option definition record. �These records have the following fields:
> • the name of the option, with the leading “-” removed
> • a space-separated list of option properties (see Option properties)
> • the help text to use for --help (omitted if the second field contains the Undocumented property).
> ….
> The help text is automatically line-wrapped before being displayed. Normally the name of the option is printed on the left-hand side of the output and the help text is printed on the right. However, if the help text contains a tab character, the text to the left of the tab is used instead of the option's name and the text to the right of the tab forms the help text. This allows you to elaborate on what type of argument the option takes.       
> “
> 
> Looks like that by design, the help text will be automatically line-wrapped before being displayed to fit on the current console. So, I think that the long line should be fine? (the only way to
> make the help text shorter line is to cut the help text). 

Hi.

I see, then it's all fine.

> 
> I also see some other options have even longer help text:
> 
>   -fcf-protection=[full|branch|return|none] Instrument functions with checks to verify jump/call/return control-flow transfer instructions have valid targets.
>   -fisolate-erroneous-paths-attribute Detect paths that trigger erroneous or undefined behavior due to a null value being used in a way forbidden by a returns_nonnull or nonnull
>                               attribute.  Isolate those paths from the main control flow and turn the statement with erroneous or undefined behavior into a trap.
>   -fisolate-erroneous-paths-dereference Detect paths that trigger erroneous or undefined behavior due to dereferencing a null pointer.  Isolate those paths from the main control flow
>                               and turn the statement with erroneous or undefined behavior into a trap.
> 

Good.

>> ...
>>
>>>
>>>> - gcc/doc/invoke.texi - 2 spaces in between sentences + better gol
>>>> - gcc/opts.c - do not mix spaces + tabs
>>>
>>> I have used contrib/check_GNU_style.sh to check the patch, I did see one place that complains about 2 spaces in between sentences, fixed it.
>>
>> I see it:
>>
>> === ERROR type #3: dot, space, space, new sentence (3 error(s)) ===
>> gcc/common.opt:2190:62:optimizations to provide a safe compilation for live-patching.â–ˆAt the same
>> gcc/doc/invoke.texi:9291:14:optimizations.â–ˆFor example, inlining a function into its caller, cloning
>> gcc/doc/invoke.texi:9297:37:impacted functions for each function.â–ˆIn order to control the number of
> 
> fixed.
> 
>>
>>> but I didn’t see spaces + tabs mix issue with the script. could you please specify?
>>
>> This is a new check that I've just installed:
>>
>> === ERROR type #1: a space should not precede a tab (1 error(s)) ===
>> gcc/opts.c:2350:0:    ████████control_optimizations_for_live_patching (opts, opts_set,
> 
> Okay, I see, fixed. 
> 
> thanks.
> 
> Qing
>>
>> Martin
>>
>>>
>>> thanks.
>>>
>>> Qing
>>> *
>>> *
> 

So please send final version of the patch.

Martin

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

[Qing Zhao]

[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]

Hi,

this is the newest version of the patch. 
major changes:
	1. format fixes raised by Martin;
	2. output error when disabled IPA optimizations are turned on explicitly by the user 
	with -flive-patching at the same time. based on Honza’s suggestions. 

the new changes have been bootstrapped and tested on both aarch64 and x86, no regressions.

Okay for commit?

thanks.

Qing.

===========
gcc/ChangeLog:

2018-11-20  qing zhao  <qing.zhao@oracle.com>

	* cif-code.def (EXTERN_LIVE_ONLY_STATIC): New CIF code.
	* common.opt: Add -flive-patching flag.
	* doc/invoke.texi: Document -flive-patching.
	* flag-types.h (enum live_patching_level): New enum.
	* ipa-inline.c (can_inline_edge_p): Disable external functions from
	inlining when flag_live_patching is LIVE_PATCHING_INLINE_ONLY_STATIC.
	* opts.c (control_options_for_live_patching): New function.
	(finish_options): Make flag_live_patching incompatible with flag_lto.
	Control IPA optimizations based on different levels of 
	flag_live_patching.

gcc/testsuite/ChangeLog:

2018-11-20  qing zhao  <qing.zhao@oracle.com>

	* gcc.dg/live-patching-1.c: New test.
	* gcc.dg/live-patching-2.c: New test.
	* gcc.dg/live-patching-3.c: New test.
	* gcc.dg/tree-ssa/writeonly-3.c: New test.
	* gcc.target/i386/ipa-stack-alignment-2.c: New test.


[-- Attachment #2: flive-patching-new.patch --]
[-- Type: application/octet-stream, Size: 16554 bytes --]

From 314a5bc2a91aaaf27554b0d2535febd9b5cfa21a Mon Sep 17 00:00:00 2001
From: qing zhao <qing.zhao@oracle.com>
Date: Mon, 19 Nov 2018 13:05:26 -0800
Subject: [PATCH] add a new option -flive-patching

---
 gcc/cif-code.def                                   |   6 +
 gcc/common.opt                                     |  18 +++
 gcc/doc/invoke.texi                                |  60 ++++++++
 gcc/flag-types.h                                   |   8 ++
 gcc/ipa-inline.c                                   |   6 +
 gcc/opts.c                                         | 154 +++++++++++++++++++++
 gcc/testsuite/gcc.dg/live-patching-1.c             |  22 +++
 gcc/testsuite/gcc.dg/live-patching-2.c             |   9 ++
 gcc/testsuite/gcc.dg/live-patching-3.c             |   9 ++
 gcc/testsuite/gcc.dg/tree-ssa/writeonly-3.c        |  20 +++
 .../gcc.target/i386/ipa-stack-alignment-2.c        |  13 ++
 11 files changed, 325 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/live-patching-1.c
 create mode 100644 gcc/testsuite/gcc.dg/live-patching-2.c
 create mode 100644 gcc/testsuite/gcc.dg/live-patching-3.c
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/writeonly-3.c
 create mode 100644 gcc/testsuite/gcc.target/i386/ipa-stack-alignment-2.c

diff --git a/gcc/cif-code.def b/gcc/cif-code.def
index 19a7621..ac3f73c 100644
--- a/gcc/cif-code.def
+++ b/gcc/cif-code.def
@@ -132,6 +132,12 @@ DEFCIFCODE(USES_COMDAT_LOCAL, CIF_FINAL_ERROR,
 DEFCIFCODE(ATTRIBUTE_MISMATCH, CIF_FINAL_ERROR,
 	   N_("function attribute mismatch"))
 
+/* We can't inline because the user requests only static functions
+   but the function has external linkage for live patching purpose.  */
+DEFCIFCODE(EXTERN_LIVE_ONLY_STATIC, CIF_FINAL_ERROR,
+	   N_("function has external linkage when the user requests only"
+	      " inlining static for live patching"))
+
 /* We proved that the call is unreachable.  */
 DEFCIFCODE(UNREACHABLE, CIF_FINAL_ERROR,
 	   N_("unreachable"))
diff --git a/gcc/common.opt b/gcc/common.opt
index 73065f5..99baab3 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2164,6 +2164,24 @@ starts and when the destructor finishes.
 flifetime-dse=
 Common Joined RejectNegative UInteger Var(flag_lifetime_dse) Optimization IntegerRange(0, 2)
 
+flive-patching
+Common RejectNegative Alias(flive-patching=,inline-clone) Optimization
+
+flive-patching=
+Common Report Joined RejectNegative Enum(live_patching_level) Var(flag_live_patching) Init(LIVE_PATCHING_NONE) Optimization
+-flive-patching=[inline-only-static|inline-clone]	Control IPA
+optimizations to provide a safe compilation for live-patching.  At the same
+time, provides multiple-level control on the enabled IPA optimizations.
+
+Enum
+Name(live_patching_level) Type(enum live_patching_level) UnknownError(unknown Live-Patching Level %qs)
+
+EnumValue
+Enum(live_patching_level) String(inline-only-static) Value(LIVE_PATCHING_INLINE_ONLY_STATIC)
+
+EnumValue
+Enum(live_patching_level) String(inline-clone) Value(LIVE_PATCHING_INLINE_CLONE)
+
 flive-range-shrinkage
 Common Report Var(flag_live_range_shrinkage) Init(0) Optimization
 Relief of register pressure through live range shrinkage.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 283d20f..d323404 100644
--- 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  -fipa-reference  -fipa-reference-addressable @gol
 -fipa-stack-alignment  -fipa-icf  -fira-algorithm=@var{algorithm} @gol
+-flive-patching=@var{level} @gol
 -fira-region=@var{region}  -fira-hoist-pressure @gol
 -fira-loop-pressure  -fno-ira-share-save-slots @gol
 -fno-ira-share-spill-slots @gol
@@ -9045,6 +9046,65 @@ equivalences that are found only by GCC and equivalences found only by Gold.
 
 This flag is enabled by default at @option{-O2} and @option{-Os}.
 
+@item -flive-patching=@var{level}
+@opindex flive-patching
+Control GCC's optimizations to provide a safe compilation for live-patching.
+
+If the compiler's optimization uses a function's body or information extracted
+from its body to optimize/change another function, the latter is called an
+impacted function of the former.  If a function is patched, its impacted
+functions should be patched too.
+
+The impacted functions are decided by the compiler's interprocedural
+optimizations.  For example, inlining a function into its caller, cloning
+a function and changing its caller to call this new clone, or extracting
+a function's pureness/constness information to optimize its direct or
+indirect callers, etc.
+
+Usually, the more IPA optimizations enabled, the larger the number of
+impacted functions for each function.  In order to control the number of
+impacted functions and computed the list of impacted function easily,
+we provide control to partially enable IPA optimizations on two different
+levels.
+
+The @var{level} argument should be one of the following:
+
+@table @samp
+
+@item inline-clone
+
+Only enable inlining and cloning optimizations, which includes inlining,
+cloning, interprocedural scalar replacement of aggregates and partial inlining.
+As a result, when patching a function, all its callers and its clones'
+callers need to be patched as well.
+
+@option{-flive-patching=inline-clone} disables the following optimization flags:
+@gccoptlist{-fwhole-program  -fipa-pta  -fipa-reference  -fipa-ra @gol
+-fipa-icf  -fipa-icf-functions  -fipa-icf-variables @gol
+-fipa-bit-cp  -fipa-vrp  -fipa-pure-const  -fipa-reference-addressable @gol
+-fipa-stack-alignment}
+
+@item inline-only-static
+
+Only enable inlining of static functions.
+As a result, when patching a static function, all its callers need to be
+patches as well.
+
+In addition to all the flags that -flive-patching=inline-clone disables,
+@option{-flive-patching=inline-only-static} disables the following additional
+optimization flags:
+@gccoptlist{-fipa-cp-clone  -fipa-sra  -fpartial-inlining  -fipa-cp}
+
+@end table
+
+When -flive-patching specified without any value, the default value
+is "inline-clone".
+
+This flag is disabled by default.
+
+Note that -flive-patching is not supported with link-time optimizer.
+(@option{-flto}).
+
 @item -fisolate-erroneous-paths-dereference
 @opindex fisolate-erroneous-paths-dereference
 Detect paths that trigger erroneous or undefined behavior due to
diff --git a/gcc/flag-types.h b/gcc/flag-types.h
index 500f663..2bbca65 100644
--- a/gcc/flag-types.h
+++ b/gcc/flag-types.h
@@ -123,6 +123,14 @@ enum stack_reuse_level
   SR_ALL
 };
 
+/* The live patching level.  */
+enum live_patching_level
+{
+  LIVE_PATCHING_NONE = 0,
+  LIVE_PATCHING_INLINE_ONLY_STATIC,
+  LIVE_PATCHING_INLINE_CLONE
+};
+
 /* The algorithm used for basic block reordering.  */
 enum reorder_blocks_algorithm
 {
diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
index 173808a..bd6ab22 100644
--- a/gcc/ipa-inline.c
+++ b/gcc/ipa-inline.c
@@ -379,6 +379,12 @@ can_inline_edge_p (struct cgraph_edge *e, bool report,
       e->inline_failed = CIF_ATTRIBUTE_MISMATCH;
       inlinable = false;
     }
+  else if (callee->externally_visible
+	   && flag_live_patching == LIVE_PATCHING_INLINE_ONLY_STATIC)
+    {
+      e->inline_failed = CIF_EXTERN_LIVE_ONLY_STATIC;
+      inlinable = false;
+    }
   if (!inlinable && report)
     report_inline_failed_reason (e);
   return inlinable;
diff --git a/gcc/opts.c b/gcc/opts.c
index e21967b..963b5fe 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -691,6 +691,148 @@ default_options_optimization (struct gcc_options *opts,
 			 lang_mask, handlers, loc, dc);
 }
 
+/* Control IPA optimizations based on different live patching LEVEL.  */
+static void
+control_options_for_live_patching (struct gcc_options *opts,
+				   struct gcc_options *opts_set,
+				   enum live_patching_level level,
+				   location_t loc)
+{
+  gcc_assert (level > LIVE_PATCHING_NONE);
+
+  switch (level)
+    {
+    case LIVE_PATCHING_INLINE_ONLY_STATIC:
+      if (opts_set->x_flag_ipa_cp_clone && opts->x_flag_ipa_cp_clone)
+	error_at (loc,
+		  "%<-fipa-cp-clone%> is incompatible with "
+		  "%<-flive-patching=inline-only-static%>");
+      else
+	opts->x_flag_ipa_cp_clone = 0;
+
+      if (opts_set->x_flag_ipa_sra && opts->x_flag_ipa_sra)
+	error_at (loc,
+		  "%<-fipa-sra%> is incompatible with "
+		  "%<-flive-patching=inline-only-static%>");
+      else
+	opts->x_flag_ipa_sra = 0;
+
+      if (opts_set->x_flag_partial_inlining && opts->x_flag_partial_inlining)
+	error_at (loc,
+		  "%<-fpartial-inlining%> is incompatible with "
+		  "%<-flive-patching=inline-only-static%>");
+      else
+	opts->x_flag_partial_inlining = 0;
+
+      if (opts_set->x_flag_ipa_cp && opts->x_flag_ipa_cp)
+	error_at (loc,
+		  "%<-fipa-cp%> is incompatible with "
+		  "%<-flive-patching=inline-only-static%>");
+      else
+	opts->x_flag_ipa_cp = 0;
+
+      /* FALLTHROUGH.  */
+    case LIVE_PATCHING_INLINE_CLONE:
+      /* live patching should disable whole-program optimization.  */
+      if (opts_set->x_flag_whole_program && opts->x_flag_whole_program)
+	error_at (loc,
+		  "%<-fwhole-program%> is incompatible with "
+		  "%<-flive-patching=inline-only-static|inline-clone%>");
+      else
+	opts->x_flag_whole_program = 0;
+
+      /* visibility change should be excluded by !flag_whole_program
+	 && !in_lto_p && !flag_ipa_cp_clone && !flag_ipa_sra
+	 && !flag_partial_inlining.  */
+
+      if (opts_set->x_flag_ipa_pta && opts->x_flag_ipa_pta)
+	error_at (loc,
+		  "%<-fipa-pta%> is incompatible with "
+		  "%<-flive-patching=inline-only-static|inline-clone%>");
+      else
+	opts->x_flag_ipa_pta = 0;
+
+      if (opts_set->x_flag_ipa_reference && opts->x_flag_ipa_reference)
+	error_at (loc,
+		  "%<-fipa-reference%> is incompatible with "
+		  "%<-flive-patching=inline-only-static|inline-clone%>");
+      else
+	opts->x_flag_ipa_reference = 0;
+
+      if (opts_set->x_flag_ipa_ra && opts->x_flag_ipa_ra)
+	error_at (loc,
+		  "%<-fipa-ra%> is incompatible with "
+		  "%<-flive-patching=inline-only-static|inline-clone%>");
+      else
+	opts->x_flag_ipa_ra = 0;
+
+      if (opts_set->x_flag_ipa_icf && opts->x_flag_ipa_icf)
+	error_at (loc,
+		  "%<-fipa-icf%> is incompatible with "
+		  "%<-flive-patching=inline-only-static|inline-clone%>");
+      else
+	opts->x_flag_ipa_icf = 0;
+
+      if (opts_set->x_flag_ipa_icf_functions && opts->x_flag_ipa_icf_functions)
+	error_at (loc,
+		  "%<-fipa-icf-functions%> is incompatible with "
+		  "%<-flive-patching=inline-only-static|inline-clone%>");
+      else
+	opts->x_flag_ipa_icf_functions = 0;
+
+      if (opts_set->x_flag_ipa_icf_variables && opts->x_flag_ipa_icf_variables)
+	error_at (loc,
+		  "%<-fipa-icf-variables%> is incompatible with "
+		  "%<-flive-patching=inline-only-static|inline-clone%>");
+      else
+	opts->x_flag_ipa_icf_variables = 0;
+
+      if (opts_set->x_flag_ipa_bit_cp && opts->x_flag_ipa_bit_cp)
+	error_at (loc,
+		  "%<-fipa-bit-cp%> is incompatible with "
+		  "%<-flive-patching=inline-only-static|inline-clone%>");
+      else
+	opts->x_flag_ipa_bit_cp = 0;
+
+      if (opts_set->x_flag_ipa_vrp && opts->x_flag_ipa_vrp)
+	error_at (loc,
+		  "%<-fipa-vrp%> is incompatible with "
+		  "%<-flive-patching=inline-only-static|inline-clone%>");
+      else
+	opts->x_flag_ipa_vrp = 0;
+
+      if (opts_set->x_flag_ipa_pure_const && opts->x_flag_ipa_pure_const)
+	error_at (loc,
+		  "%<-fipa-pure-const%> is incompatible with "
+		  "%<-flive-patching=inline-only-static|inline-clone%>");
+      else
+	opts->x_flag_ipa_pure_const = 0;
+
+      /* FIXME: disable unreachable code removal.  */
+
+      /* discovery of functions/variables with no address taken.  */
+      if (opts_set->x_flag_ipa_reference_addressable
+	  && opts->x_flag_ipa_reference_addressable)
+	error_at (loc,
+		  "%<-fipa-reference-addressable%> is incompatible with "
+		  "%<-flive-patching=inline-only-static|inline-clone%>");
+      else
+	opts->x_flag_ipa_reference_addressable = 0;
+
+      /* ipa stack alignment propagation.  */
+      if (opts_set->x_flag_ipa_stack_alignment
+	  && opts->x_flag_ipa_stack_alignment)
+	error_at (loc,
+		  "%<-fipa-stack-alignment%> is incompatible with "
+		  "%<-flive-patching=inline-only-static|inline-clone%>");
+      else
+	opts->x_flag_ipa_stack_alignment = 0;
+      break;
+    default:
+      gcc_unreachable ();
+    }
+}
+
 /* After all options at LOC have been read into OPTS and OPTS_SET,
    finalize settings of those options and diagnose incompatible
    combinations.  */
@@ -1040,6 +1182,18 @@ finish_options (struct gcc_options *opts, struct gcc_options *opts_set,
   if ((opts->x_flag_sanitize & SANITIZE_KERNEL_ADDRESS) && opts->x_flag_tm)
     sorry ("transactional memory is not supported with "
 	   "%<-fsanitize=kernel-address%>");
+
+  /* Currently live patching is not support for LTO.  */
+  if (opts->x_flag_live_patching && opts->x_flag_lto)
+    sorry ("live patching is not supported with LTO");
+
+  /* Control IPA optimizations based on different -flive-patching level.  */
+  if (opts->x_flag_live_patching)
+    {
+      control_options_for_live_patching (opts, opts_set,
+					 opts->x_flag_live_patching,
+					 loc);
+    }
 }
 
 #define LEFT_COLUMN	27
diff --git a/gcc/testsuite/gcc.dg/live-patching-1.c b/gcc/testsuite/gcc.dg/live-patching-1.c
new file mode 100644
index 0000000..6a1ea38
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/live-patching-1.c
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -flive-patching=inline-only-static -fdump-ipa-inline" } */
+
+extern int sum, n, m;
+
+int foo (int a)
+{
+  return a + n;
+}
+
+static int bar (int b)
+{
+  return b * m;
+}
+
+int main()
+{
+  sum = foo (m) + bar (n); 
+  return 0;
+}
+
+/* { dg-final { scan-ipa-dump "foo/0 function has external linkage when the user requests only inlining static for live patching"  "inline" } } */
diff --git a/gcc/testsuite/gcc.dg/live-patching-2.c b/gcc/testsuite/gcc.dg/live-patching-2.c
new file mode 100644
index 0000000..b418aaf
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/live-patching-2.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -flive-patching -flto" } */
+
+int main()
+{
+  return 0;
+}
+
+/* { dg-message "sorry, unimplemented: live patching is not supported with LTO" "-flive-patching and -flto together" { target *-*-* } 0 } */
diff --git a/gcc/testsuite/gcc.dg/live-patching-3.c b/gcc/testsuite/gcc.dg/live-patching-3.c
new file mode 100644
index 0000000..b86f3c6
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/live-patching-3.c
@@ -0,0 +1,9 @@
+/* { dg-do compile } */
+/* { dg-options "-O1 -flive-patching -fwhole-program" } */
+
+int main()
+{
+  return 0;
+}
+
+/* { dg-message "'-fwhole-program' is incompatible with '-flive-patching=inline-only-static|inline-clone’" "" {target "*-*-*"} 0 } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/writeonly-3.c b/gcc/testsuite/gcc.dg/tree-ssa/writeonly-3.c
new file mode 100644
index 0000000..4be4cf7
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/writeonly-3.c
@@ -0,0 +1,20 @@
+/* { dg-do compile } */
+/* { dg-options "-O1 -fdump-tree-optimized -flive-patching" } */
+static struct a {int magic1,b;} a;
+volatile int magic2;
+static struct b {int a,b,c,d,e,f;} magic3;
+
+struct b foo();
+
+void
+t()
+{
+ a.magic1 = 1;
+ magic2 = 1;
+ magic3 = foo();
+}
+/* { dg-final { scan-tree-dump "magic1" "optimized"} } */
+/* { dg-final { scan-tree-dump "magic3" "optimized"} } */
+/* { dg-final { scan-tree-dump "magic2" "optimized"} } */
+/* { dg-final { scan-tree-dump "foo" "optimized"} } */
+ 
diff --git a/gcc/testsuite/gcc.target/i386/ipa-stack-alignment-2.c b/gcc/testsuite/gcc.target/i386/ipa-stack-alignment-2.c
new file mode 100644
index 0000000..8ba7000
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/ipa-stack-alignment-2.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-flive-patching -O" } */
+
+typedef struct {
+  long a;
+  long b[];
+} c;
+
+c *d;
+void e() { d->b[0] = 5; }
+void f() { e(); }
+
+/* { dg-final { scan-assembler "sub.*%.sp" } } */
-- 
1.9.1

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

[Qing Zhao]

Hi, 
I’d like to ping the following patch for adding -flive-patching master option.

https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01729.html <https://gcc.gnu.org/ml/gcc-patches/2018-11/msg01729.html>

thanks.

Qing




> On Nov 20, 2018, at 9:32 AM, Qing Zhao <qing.zhao@oracle.com> wrote:
> 
> Hi,
> 
> this is the newest version of the patch. 
> major changes:
> 	1. format fixes raised by Martin;
> 	2. output error when disabled IPA optimizations are turned on explicitly by the user 
> 	with -flive-patching at the same time. based on Honza’s suggestions. 
> 
> the new changes have been bootstrapped and tested on both aarch64 and x86, no regressions.
> 
> Okay for commit?
> 
> thanks.
> 
> Qing.
> 
> ===========
> gcc/ChangeLog:
> 
> 2018-11-20  qing zhao  <qing.zhao@oracle.com>
> 
> 	* cif-code.def (EXTERN_LIVE_ONLY_STATIC): New CIF code.
> 	* common.opt: Add -flive-patching flag.
> 	* doc/invoke.texi: Document -flive-patching.
> 	* flag-types.h (enum live_patching_level): New enum.
> 	* ipa-inline.c (can_inline_edge_p): Disable external functions from
> 	inlining when flag_live_patching is LIVE_PATCHING_INLINE_ONLY_STATIC.
> 	* opts.c (control_options_for_live_patching): New function.
> 	(finish_options): Make flag_live_patching incompatible with flag_lto.
> 	Control IPA optimizations based on different levels of 
> 	flag_live_patching.
> 
> gcc/testsuite/ChangeLog:
> 
> 2018-11-20  qing zhao  <qing.zhao@oracle.com>
> 
> 	* gcc.dg/live-patching-1.c: New test.
> 	* gcc.dg/live-patching-2.c: New test.
> 	* gcc.dg/live-patching-3.c: New test.
> 	* gcc.dg/tree-ssa/writeonly-3.c: New test.
> 	* gcc.target/i386/ipa-stack-alignment-2.c: New test.
> 
> <flive-patching-new.patch>

[wwwdocs] [PATCH]introduce new -flive-patching master option into gcc9

[Qing Zhao]

Hi,

This is the patch for update https://gcc.gnu.org/gcc-9/changes.html <https://gcc.gnu.org/gcc-9/changes.html> to include the introducing of new option
-flive-patching into gcc9.

Okay for commit?

thanks.
Qing

=====
Index: gcc-9/changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-9/changes.html,v
retrieving revision 1.28
diff -u -r1.28 changes.html
--- gcc-9/changes.html	21 Nov 2018 20:07:26 -0000	1.28
+++ gcc-9/changes.html	30 Nov 2018 16:50:16 -0000
@@ -48,6 +48,15 @@
 
 <!-- .................................................................. -->
 <h2 id="general">General Improvements</h2>
+<ul>
+  <li>
+    A new option -flive-patching=[inline-only-static|inline-clone] is 
+    introduced to provide a safe compilation for live-patching. At the same
+    time, provides multiple-level control on the enabled IPA optimizations.
+    See the user guide for further information about the option for more
+    details. 
+  </li>
+</ul>
 
 <!-- .................................................................. -->
 <h2 id="languages">New Languages and Language specific improvements</h2>


On Nov 20, 2018, at 9:32 AM, Qing Zhao <qing.zhao@oracle.com> wrote:
>> 
>> 
>> Qing.
>> 
>> ===========
>> gcc/ChangeLog:
>> 
>> 2018-11-20  qing zhao  <qing.zhao@oracle.com>
>> 
>> 	* cif-code.def (EXTERN_LIVE_ONLY_STATIC): New CIF code.
>> 	* common.opt: Add -flive-patching flag.
>> 	* doc/invoke.texi: Document -flive-patching.
>> 	* flag-types.h (enum live_patching_level): New enum.
>> 	* ipa-inline.c (can_inline_edge_p): Disable external functions from
>> 	inlining when flag_live_patching is LIVE_PATCHING_INLINE_ONLY_STATIC.
>> 	* opts.c (control_options_for_live_patching): New function.
>> 	(finish_options): Make flag_live_patching incompatible with flag_lto.
>> 	Control IPA optimizations based on different levels of 
>> 	flag_live_patching.
>> 
>> gcc/testsuite/ChangeLog:
>> 
>> 2018-11-20  qing zhao  <qing.zhao@oracle.com>
>> 
>> 	* gcc.dg/live-patching-1.c: New test.
>> 	* gcc.dg/live-patching-2.c: New test.
>> 	* gcc.dg/live-patching-3.c: New test.
>> 	* gcc.dg/tree-ssa/writeonly-3.c: New test.
>> 	* gcc.target/i386/ipa-stack-alignment-2.c: New test.
>> 
>> <flive-patching-new.patch>
> 

Re: [wwwdocs] [PATCH]introduce new -flive-patching master option into gcc9

[Jeff Law]

On 11/30/18 10:03 AM, Qing Zhao wrote:
> Hi,
> 
> This is the patch for update https://gcc.gnu.org/gcc-9/changes.html <https://gcc.gnu.org/gcc-9/changes.html> to include the introducing of new option
> -flive-patching into gcc9.
> 
> Okay for commit?
OK
jeff

Re: [wwwdocs] [PATCH]introduce new -flive-patching master option into gcc9

[Qing Zhao]

just checked in the change.

https://gcc.gnu.org/gcc-9/changes.html <https://gcc.gnu.org/gcc-9/changes.html>

thanks.

Qing
> On Nov 30, 2018, at 12:28 PM, Jeff Law <law@redhat.com> wrote:
> 
> On 11/30/18 10:03 AM, Qing Zhao wrote:
>> Hi,
>> 
>> This is the patch for update https://gcc.gnu.org/gcc-9/changes.html <https://gcc.gnu.org/gcc-9/changes.html> to include the introducing of new option
>> -flive-patching into gcc9.
>> 
>> Okay for commit?
> OK
> jeff

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

[Jan Hubicka]

> 
> 2018-11-20  qing zhao  <qing.zhao@oracle.com>
> 
> 	* cif-code.def (EXTERN_LIVE_ONLY_STATIC): New CIF code.
> 	* common.opt: Add -flive-patching flag.
> 	* doc/invoke.texi: Document -flive-patching.
> 	* flag-types.h (enum live_patching_level): New enum.
> 	* ipa-inline.c (can_inline_edge_p): Disable external functions from
> 	inlining when flag_live_patching is LIVE_PATCHING_INLINE_ONLY_STATIC.
> 	* opts.c (control_options_for_live_patching): New function.
> 	(finish_options): Make flag_live_patching incompatible with flag_lto.
> 	Control IPA optimizations based on different levels of 
> 	flag_live_patching.
> 
> gcc/testsuite/ChangeLog:
> 
> 2018-11-20  qing zhao  <qing.zhao@oracle.com>
> 
> 	* gcc.dg/live-patching-1.c: New test.
> 	* gcc.dg/live-patching-2.c: New test.
> 	* gcc.dg/live-patching-3.c: New test.
> 	* gcc.dg/tree-ssa/writeonly-3.c: New test.
> 	* gcc.target/i386/ipa-stack-alignment-2.c: New test.
> 

I am still somewhat worried about possible use with C++ programs where
we will kill all inlining of comdats, but I guess we could discuss that
when it becomes an issue.
+
+      /* FIXME: disable unreachable code removal.  */

Disabling unreachable code removal will really introduce a lot of extra
dead code, can't live patches just provide what they need if the code
was earlier removed.
+
+      /* discovery of functions/variables with no address taken.  */
+      if (opts_set->x_flag_ipa_reference_addressable
+	  && opts->x_flag_ipa_reference_addressable)
+	error_at (loc,
+		  "%<-fipa-reference-addressable%> is incompatible with "
+		  "%<-flive-patching=inline-only-static|inline-clone%>");
+      else
+	opts->x_flag_ipa_reference_addressable = 0;
+
+      /* ipa stack alignment propagation.  */
+      if (opts_set->x_flag_ipa_stack_alignment
+	  && opts->x_flag_ipa_stack_alignment)
+	error_at (loc,
+		  "%<-fipa-stack-alignment%> is incompatible with "
+		  "%<-flive-patching=inline-only-static|inline-clone%>");
+      else
+	opts->x_flag_ipa_stack_alignment = 0;

Shall we also disable nothrow or we will worry about C++ only ter?

Patch is OK,
thanks!
Honza

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

[Qing Zhao]

> On Nov 28, 2018, at 9:52 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
> 
>> 
>> 2018-11-20  qing zhao  <qing.zhao@oracle.com>
>> 
>> 	* cif-code.def (EXTERN_LIVE_ONLY_STATIC): New CIF code.
>> 	* common.opt: Add -flive-patching flag.
>> 	* doc/invoke.texi: Document -flive-patching.
>> 	* flag-types.h (enum live_patching_level): New enum.
>> 	* ipa-inline.c (can_inline_edge_p): Disable external functions from
>> 	inlining when flag_live_patching is LIVE_PATCHING_INLINE_ONLY_STATIC.
>> 	* opts.c (control_options_for_live_patching): New function.
>> 	(finish_options): Make flag_live_patching incompatible with flag_lto.
>> 	Control IPA optimizations based on different levels of 
>> 	flag_live_patching.
>> 
>> gcc/testsuite/ChangeLog:
>> 
>> 2018-11-20  qing zhao  <qing.zhao@oracle.com>
>> 
>> 	* gcc.dg/live-patching-1.c: New test.
>> 	* gcc.dg/live-patching-2.c: New test.
>> 	* gcc.dg/live-patching-3.c: New test.
>> 	* gcc.dg/tree-ssa/writeonly-3.c: New test.
>> 	* gcc.target/i386/ipa-stack-alignment-2.c: New test.
>> 
> 
> I am still somewhat worried about possible use with C++ programs where
> we will kill all inlining of comdats, but I guess we could discuss that
> when it becomes an issue.

Okay. If this will be a problem later when we use live-patching in more C++ applications, let’s 
revisit it at that time. 

> +
> +      /* FIXME: disable unreachable code removal.  */
> 
> Disabling unreachable code removal will really introduce a lot of extra
> dead code, can't live patches just provide what they need if the code
> was earlier removed.
> +
> +      /* discovery of functions/variables with no address taken.  */
> +      if (opts_set->x_flag_ipa_reference_addressable
> +	  && opts->x_flag_ipa_reference_addressable)
> +	error_at (loc,
> +		  "%<-fipa-reference-addressable%> is incompatible with "
> +		  "%<-flive-patching=inline-only-static|inline-clone%>");
> +      else
> +	opts->x_flag_ipa_reference_addressable = 0;
> +
> +      /* ipa stack alignment propagation.  */
> +      if (opts_set->x_flag_ipa_stack_alignment
> +	  && opts->x_flag_ipa_stack_alignment)
> +	error_at (loc,
> +		  "%<-fipa-stack-alignment%> is incompatible with "
> +		  "%<-flive-patching=inline-only-static|inline-clone%>");
> +      else
> +	opts->x_flag_ipa_stack_alignment = 0;
> 
> 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.
But I can add a separate simple patch to add another flag to control nothrow propagation and disable it when -flive-patching is ON.

> 
> Patch is OK,

thanks for the review.

I will commit the patch very soon.

Qing
> thanks!
> Honza

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

[Qing Zhao]

the patch has been committed today as:

https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=266627 <https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=266627>

I will try to update the gcc9 change page soon.

thanks.

Qing

> On Nov 28, 2018, at 2:24 PM, Qing Zhao <qing.zhao@oracle.com> wrote:
> 
>> 
>> On Nov 28, 2018, at 9:52 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> 
>>> 
>>> 2018-11-20  qing zhao  <qing.zhao@oracle.com>
>>> 
>>> 	* cif-code.def (EXTERN_LIVE_ONLY_STATIC): New CIF code.
>>> 	* common.opt: Add -flive-patching flag.
>>> 	* doc/invoke.texi: Document -flive-patching.
>>> 	* flag-types.h (enum live_patching_level): New enum.
>>> 	* ipa-inline.c (can_inline_edge_p): Disable external functions from
>>> 	inlining when flag_live_patching is LIVE_PATCHING_INLINE_ONLY_STATIC.
>>> 	* opts.c (control_options_for_live_patching): New function.
>>> 	(finish_options): Make flag_live_patching incompatible with flag_lto.
>>> 	Control IPA optimizations based on different levels of 
>>> 	flag_live_patching.
>>> 
>>> gcc/testsuite/ChangeLog:
>>> 
>>> 2018-11-20  qing zhao  <qing.zhao@oracle.com>
>>> 
>>> 	* gcc.dg/live-patching-1.c: New test.
>>> 	* gcc.dg/live-patching-2.c: New test.
>>> 	* gcc.dg/live-patching-3.c: New test.
>>> 	* gcc.dg/tree-ssa/writeonly-3.c: New test.
>>> 	* gcc.target/i386/ipa-stack-alignment-2.c: New test.
>>> 
>> 
>> I am still somewhat worried about possible use with C++ programs where
>> we will kill all inlining of comdats, but I guess we could discuss that
>> when it becomes an issue.
> 
> Okay. If this will be a problem later when we use live-patching in more C++ applications, let’s 
> revisit it at that time. 
> 
>> +
>> +      /* FIXME: disable unreachable code removal.  */
>> 
>> Disabling unreachable code removal will really introduce a lot of extra
>> dead code, can't live patches just provide what they need if the code
>> was earlier removed.
>> +
>> +      /* discovery of functions/variables with no address taken.  */
>> +      if (opts_set->x_flag_ipa_reference_addressable
>> +	  && opts->x_flag_ipa_reference_addressable)
>> +	error_at (loc,
>> +		  "%<-fipa-reference-addressable%> is incompatible with "
>> +		  "%<-flive-patching=inline-only-static|inline-clone%>");
>> +      else
>> +	opts->x_flag_ipa_reference_addressable = 0;
>> +
>> +      /* ipa stack alignment propagation.  */
>> +      if (opts_set->x_flag_ipa_stack_alignment
>> +	  && opts->x_flag_ipa_stack_alignment)
>> +	error_at (loc,
>> +		  "%<-fipa-stack-alignment%> is incompatible with "
>> +		  "%<-flive-patching=inline-only-static|inline-clone%>");
>> +      else
>> +	opts->x_flag_ipa_stack_alignment = 0;
>> 
>> 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.
> But I can add a separate simple patch to add another flag to control nothrow propagation and disable it when -flive-patching is ON.
> 
>> 
>> Patch is OK,
> 
> thanks for the review.
> 
> I will commit the patch very soon.
> 
> Qing
>> thanks!
>> Honza

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

[Qing Zhao]

Hi, Honza,

I have one question relate to whether to disable nothrow for -flive-patching as following:

actually, there are two passes here:

1. local nothrow pass:  in this pass, nothrow attribute is set locally after analyzing every stmt of the function
body: 

unsigned int
pass_nothrow::execute (function *)
{
  struct cgraph_node *node;
  basic_block this_block;
…

}

2. nothrow propagation pass:  (it’s included in the ipa_pure_const pass as following, propagate the nothrow 
attribute along callcgraph)

unsigned int
pass_ipa_pure_const::
execute (function *)
{
  bool remove_p;

  /* Nothrow makes more function to not lead to return and improve
     later analysis.  */
  propagate_nothrow ();
  propagate_malloc ();
  remove_p = propagate_pure_const ();

  delete funct_state_summaries;
  return remove_p ? TODO_remove_functions : 0;
}

the nothrow propagation pass is included in ipa_pure_const pass, and is guarded by flag_ipa_pure_const, 
this flag_ipa_pure_const is disabled when -flive-patching is ON.


So, my question is:

shall we disable local nothrow pass as well when -flive-patching is ON?

my understanding is: we should. 

the reason is:   the local nothrow pass is setting the nothrow attribute for the current routine based on its
body,  and this “nothrow” attribute will be used  when generating EH code around callsite from the caller
of the routine. so the nothrow attribute might impact other routines than the current routine.  as a result,
we should disable this pass?

what’s your opinion on this?

thanks.

Qing

> On Nov 28, 2018, at 2:24 PM, Qing Zhao <qing.zhao@oracle.com> 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.
> But I can add a separate simple patch to add another flag to control nothrow propagation and disable it when -flive-patching is ON.
> 
>> 
>> Patch is OK,
> 
> thanks for the review.
> 
> I will commit the patch very soon.
> 
> Qing
>> thanks!
>> Honza

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

[Martin Liška]

Honza: PING

On 12/6/18 12:16 AM, Qing Zhao wrote:
> Hi, Honza,
> 
> I have one question relate to whether to disable nothrow for -flive-patching as following:
> 
> actually, there are two passes here:
> 
> 1. local nothrow pass:  in this pass, nothrow attribute is set locally after analyzing every stmt of the function
> body: 
> 
> unsigned int
> pass_nothrow::execute (function *)
> {
>   struct cgraph_node *node;
>   basic_block this_block;
> …
> 
> }
> 
> 2. nothrow propagation pass:  (it’s included in the ipa_pure_const pass as following, propagate the nothrow 
> attribute along callcgraph)
> 
> unsigned int
> pass_ipa_pure_const::
> execute (function *)
> {
>   bool remove_p;
> 
>   /* Nothrow makes more function to not lead to return and improve
>      later analysis.  */
>   propagate_nothrow ();
>   propagate_malloc ();
>   remove_p = propagate_pure_const ();
> 
>   delete funct_state_summaries;
>   return remove_p ? TODO_remove_functions : 0;
> }
> 
> the nothrow propagation pass is included in ipa_pure_const pass, and is guarded by flag_ipa_pure_const, 
> this flag_ipa_pure_const is disabled when -flive-patching is ON.
> 
> 
> So, my question is:
> 
> shall we disable local nothrow pass as well when -flive-patching is ON?
> 
> my understanding is: we should. 
> 
> the reason is:   the local nothrow pass is setting the nothrow attribute for the current routine based on its
> body,  and this “nothrow” attribute will be used  when generating EH code around callsite from the caller
> of the routine. so the nothrow attribute might impact other routines than the current routine.  as a result,
> we should disable this pass?
> 
> what’s your opinion on this?
> 
> thanks.
> 
> Qing
> 
>> On Nov 28, 2018, at 2:24 PM, Qing Zhao <qing.zhao@oracle.com <mailto:qing.zhao@oracle.com>> 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.
>> But I can add a separate simple patch to add another flag to control nothrow propagation and disable it when -flive-patching is ON.
>>
>>>
>>> Patch is OK,
>>
>> thanks for the review.
>>
>> I will commit the patch very soon.
>>
>> Qing
>>> thanks!
>>> Honza
> 

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

[Martin Liška]

Honza: PING^2

On 1/2/19 12:47 PM, Martin Liška wrote:
> Honza: PING
> 
> On 12/6/18 12:16 AM, Qing Zhao wrote:
>> Hi, Honza,
>>
>> I have one question relate to whether to disable nothrow for -flive-patching as following:
>>
>> actually, there are two passes here:
>>
>> 1. local nothrow pass:  in this pass, nothrow attribute is set locally after analyzing every stmt of the function
>> body: 
>>
>> unsigned int
>> pass_nothrow::execute (function *)
>> {
>>   struct cgraph_node *node;
>>   basic_block this_block;
>> …
>>
>> }
>>
>> 2. nothrow propagation pass:  (it’s included in the ipa_pure_const pass as following, propagate the nothrow 
>> attribute along callcgraph)
>>
>> unsigned int
>> pass_ipa_pure_const::
>> execute (function *)
>> {
>>   bool remove_p;
>>
>>   /* Nothrow makes more function to not lead to return and improve
>>      later analysis.  */
>>   propagate_nothrow ();
>>   propagate_malloc ();
>>   remove_p = propagate_pure_const ();
>>
>>   delete funct_state_summaries;
>>   return remove_p ? TODO_remove_functions : 0;
>> }
>>
>> the nothrow propagation pass is included in ipa_pure_const pass, and is guarded by flag_ipa_pure_const, 
>> this flag_ipa_pure_const is disabled when -flive-patching is ON.
>>
>>
>> So, my question is:
>>
>> shall we disable local nothrow pass as well when -flive-patching is ON?
>>
>> my understanding is: we should. 
>>
>> the reason is:   the local nothrow pass is setting the nothrow attribute for the current routine based on its
>> body,  and this “nothrow” attribute will be used  when generating EH code around callsite from the caller
>> of the routine. so the nothrow attribute might impact other routines than the current routine.  as a result,
>> we should disable this pass?
>>
>> what’s your opinion on this?
>>
>> thanks.
>>
>> Qing
>>
>>> On Nov 28, 2018, at 2:24 PM, Qing Zhao <qing.zhao@oracle.com <mailto:qing.zhao@oracle.com>> 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.
>>> But I can add a separate simple patch to add another flag to control nothrow propagation and disable it when -flive-patching is ON.
>>>
>>>>
>>>> Patch is OK,
>>>
>>> thanks for the review.
>>>
>>> I will commit the patch very soon.
>>>
>>> Qing
>>>> thanks!
>>>> Honza
>>

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

[Rainer Orth]

[-- Attachment #1: Type: text/plain, Size: 1773 bytes --]

Hi Qing,

>> On Nov 28, 2018, at 9:52 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>> 
>>> 
>>> 2018-11-20  qing zhao  <qing.zhao@oracle.com>
>>> 
>>> 	* cif-code.def (EXTERN_LIVE_ONLY_STATIC): New CIF code.
>>> 	* common.opt: Add -flive-patching flag.
>>> 	* doc/invoke.texi: Document -flive-patching.
>>> 	* flag-types.h (enum live_patching_level): New enum.
>>> 	* ipa-inline.c (can_inline_edge_p): Disable external functions from
>>> 	inlining when flag_live_patching is LIVE_PATCHING_INLINE_ONLY_STATIC.
>>> 	* opts.c (control_options_for_live_patching): New function.
>>> 	(finish_options): Make flag_live_patching incompatible with flag_lto.
>>> 	Control IPA optimizations based on different levels of 
>>> 	flag_live_patching.
>>> 
>>> gcc/testsuite/ChangeLog:
>>> 
>>> 2018-11-20  qing zhao  <qing.zhao@oracle.com>
>>> 
>>> 	* gcc.dg/live-patching-1.c: New test.
>>> 	* gcc.dg/live-patching-2.c: New test.
>>> 	* gcc.dg/live-patching-3.c: New test.
>>> 	* gcc.dg/tree-ssa/writeonly-3.c: New test.
>>> 	* gcc.target/i386/ipa-stack-alignment-2.c: New test.
[...]
>> Patch is OK,
>
> thanks for the review.
>
> I will commit the patch very soon.

the new gcc.target/i386/ipa-stack-alignment-2.c testcase FAILs on
Solaris/x86:

FAIL: gcc.target/i386/ipa-stack-alignment-2.c scan-assembler sub.*%.sp

Like ipa-stack-alignment.c, it needs -fomit-frame-pointer.  Fixed as
follows, tested on i386-pc-solaris2.11 and x86_64-pc-linux-gnu, 32 and
64-bit each.  Installed on mainline.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University


2018-12-06  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	* gcc.target/i386/ipa-stack-alignment-2.c: Add
	-fomit-frame-pointer to dg-options.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: testsuite-i386-ipa-stack-alignment-2.patch --]
[-- Type: text/x-patch, Size: 567 bytes --]

# HG changeset patch
# Parent  580b8c24b018674f1ffd56a9c672129f746682c5
Build gcc.target/i386/ipa-stack-alignment-2.c with -fomit-frame-pointer

diff --git a/gcc/testsuite/gcc.target/i386/ipa-stack-alignment-2.c b/gcc/testsuite/gcc.target/i386/ipa-stack-alignment-2.c
--- a/gcc/testsuite/gcc.target/i386/ipa-stack-alignment-2.c
+++ b/gcc/testsuite/gcc.target/i386/ipa-stack-alignment-2.c
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-flive-patching -O" } */
+/* { dg-options "-flive-patching -O -fomit-frame-pointer" } */
 
 typedef struct {
   long a;

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

[Qing Zhao]

thanks a lot for fixing this issue.

Qing
> On Dec 7, 2018, at 7:07 AM, Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote:
> 
> Hi Qing,
> 
>>> On Nov 28, 2018, at 9:52 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>>> 
>>>> 
>>>> 2018-11-20  qing zhao  <qing.zhao@oracle.com>
>>>> 
>>>> 	* cif-code.def (EXTERN_LIVE_ONLY_STATIC): New CIF code.
>>>> 	* common.opt: Add -flive-patching flag.
>>>> 	* doc/invoke.texi: Document -flive-patching.
>>>> 	* flag-types.h (enum live_patching_level): New enum.
>>>> 	* ipa-inline.c (can_inline_edge_p): Disable external functions from
>>>> 	inlining when flag_live_patching is LIVE_PATCHING_INLINE_ONLY_STATIC.
>>>> 	* opts.c (control_options_for_live_patching): New function.
>>>> 	(finish_options): Make flag_live_patching incompatible with flag_lto.
>>>> 	Control IPA optimizations based on different levels of 
>>>> 	flag_live_patching.
>>>> 
>>>> gcc/testsuite/ChangeLog:
>>>> 
>>>> 2018-11-20  qing zhao  <qing.zhao@oracle.com>
>>>> 
>>>> 	* gcc.dg/live-patching-1.c: New test.
>>>> 	* gcc.dg/live-patching-2.c: New test.
>>>> 	* gcc.dg/live-patching-3.c: New test.
>>>> 	* gcc.dg/tree-ssa/writeonly-3.c: New test.
>>>> 	* gcc.target/i386/ipa-stack-alignment-2.c: New test.
> [...]
>>> Patch is OK,
>> 
>> thanks for the review.
>> 
>> I will commit the patch very soon.
> 
> the new gcc.target/i386/ipa-stack-alignment-2.c testcase FAILs on
> Solaris/x86:
> 
> FAIL: gcc.target/i386/ipa-stack-alignment-2.c scan-assembler sub.*%.sp
> 
> Like ipa-stack-alignment.c, it needs -fomit-frame-pointer.  Fixed as
> follows, tested on i386-pc-solaris2.11 and x86_64-pc-linux-gnu, 32 and
> 64-bit each.  Installed on mainline.
> 
> 	Rainer
> 
> -- 
> -----------------------------------------------------------------------------
> Rainer Orth, Center for Biotechnology, Bielefeld University
> 
> 
> 2018-12-06  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
> 
> 	* gcc.target/i386/ipa-stack-alignment-2.c: Add
> 	-fomit-frame-pointer to dg-options.
> 
> # HG changeset patch
> # Parent  580b8c24b018674f1ffd56a9c672129f746682c5
> Build gcc.target/i386/ipa-stack-alignment-2.c with -fomit-frame-pointer
> 
> diff --git a/gcc/testsuite/gcc.target/i386/ipa-stack-alignment-2.c b/gcc/testsuite/gcc.target/i386/ipa-stack-alignment-2.c
> --- a/gcc/testsuite/gcc.target/i386/ipa-stack-alignment-2.c
> +++ b/gcc/testsuite/gcc.target/i386/ipa-stack-alignment-2.c
> @@ -1,5 +1,5 @@
> /* { dg-do compile } */
> -/* { dg-options "-flive-patching -O" } */
> +/* { dg-options "-flive-patching -O -fomit-frame-pointer" } */
> 
> typedef struct {
>   long a;

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

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 6300 bytes --]

On 20/11/18 09:32 -0600, Qing Zhao wrote:
>Hi,
>
>this is the newest version of the patch.
>major changes:
>	1. format fixes raised by Martin;
>	2. output error when disabled IPA optimizations are turned on explicitly by the user
>	with -flive-patching at the same time. based on Honza’s suggestions.
>
>the new changes have been bootstrapped and tested on both aarch64 and x86, no regressions.
>
>Okay for commit?
>
>thanks.
>
>Qing.
>
>===========
>gcc/ChangeLog:
>
>2018-11-20  qing zhao  <qing.zhao@oracle.com>
>
>	* cif-code.def (EXTERN_LIVE_ONLY_STATIC): New CIF code.
>	* common.opt: Add -flive-patching flag.
>	* doc/invoke.texi: Document -flive-patching.
>	* flag-types.h (enum live_patching_level): New enum.
>	* ipa-inline.c (can_inline_edge_p): Disable external functions from
>	inlining when flag_live_patching is LIVE_PATCHING_INLINE_ONLY_STATIC.
>	* opts.c (control_options_for_live_patching): New function.
>	(finish_options): Make flag_live_patching incompatible with flag_lto.
>	Control IPA optimizations based on different levels of
>	flag_live_patching.
>
>gcc/testsuite/ChangeLog:
>
>2018-11-20  qing zhao  <qing.zhao@oracle.com>
>
>	* gcc.dg/live-patching-1.c: New test.
>	* gcc.dg/live-patching-2.c: New test.
>	* gcc.dg/live-patching-3.c: New test.
>	* gcc.dg/tree-ssa/writeonly-3.c: New test.
>	* gcc.target/i386/ipa-stack-alignment-2.c: New test.
>


Hi Qing Zhao,

I was looking at the new docs for -flive-patching and have some
questions.

>--- 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  -fipa-reference  -fipa-reference-addressable @gol
> -fipa-stack-alignment  -fipa-icf  -fira-algorithm=@var{algorithm} @gol
>+-flive-patching=@var{level} @gol
> -fira-region=@var{region}  -fira-hoist-pressure @gol
> -fira-loop-pressure  -fno-ira-share-save-slots @gol
> -fno-ira-share-spill-slots @gol
>@@ -9045,6 +9046,65 @@ equivalences that are found only by GCC and equivalences found only by Gold.
> 
> This flag is enabled by default at @option{-O2} and @option{-Os}.
> 
>+@item -flive-patching=@var{level}
>+@opindex flive-patching
>+Control GCC's optimizations to provide a safe compilation for live-patching.

"provide a safe compilation" isn't very clear to me. I don't know what
it means to "provide a compilation", let alone a safe one.

Could we say something like "Control GCC’s optimizations to produce
output suitable for live-patching." ?


>+If the compiler's optimization uses a function's body or information extracted
>+from its body to optimize/change another function, the latter is called an
>+impacted function of the former.  If a function is patched, its impacted
>+functions should be patched too.
>+
>+The impacted functions are decided by the compiler's interprocedural

decided or determined?

>+optimizations.  For example, inlining a function into its caller, cloning
>+a function and changing its caller to call this new clone, or extracting
>+a function's pureness/constness information to optimize its direct or
>+indirect callers, etc.

I don't know what the second sentence is saying. I can read it two
different ways:

1) Those are examples of interprocedural optimizations which
participate in the decision making, but the actual details of how the
decisions are made are not specified here.

2) Performing those optimizations causes a function to be impacted.

If 1) is the intended meaning, then I think it should say "For
example, <INS>when</INS> inlining a function into its caller, ..."

If 2) is the intended meaning, then I think it should say "For
example, <INS>a caller is impacted when</INS> inlining a function
into its caller ...".

Does either of those suggestions match the intended meaning? Or do you
have a better way to rephrase it?

>+Usually, the more IPA optimizations enabled, the larger the number of
>+impacted functions for each function.  In order to control the number of
>+impacted functions and computed the list of impacted function easily,

Should be "and more easily compute the list of impacted functions".

>+we provide control to partially enable IPA optimizations on two different
>+levels.

We don't usually say "we provide" like this. I suggest simply "IPA
optimizations can be partially enabled at two different levels."

>+
>+The @var{level} argument should be one of the following:
>+
>+@table @samp
>+
>+@item inline-clone
>+
>+Only enable inlining and cloning optimizations, which includes inlining,
>+cloning, interprocedural scalar replacement of aggregates and partial inlining.
>+As a result, when patching a function, all its callers and its clones'
>+callers need to be patched as well.

Since you've defined the term "impacted" could this just say "all its
callers and its clones' callers are impacted."?

>+@option{-flive-patching=inline-clone} disables the following optimization flags:
>+@gccoptlist{-fwhole-program  -fipa-pta  -fipa-reference  -fipa-ra @gol
>+-fipa-icf  -fipa-icf-functions  -fipa-icf-variables @gol
>+-fipa-bit-cp  -fipa-vrp  -fipa-pure-const  -fipa-reference-addressable @gol
>+-fipa-stack-alignment}
>+
>+@item inline-only-static
>+
>+Only enable inlining of static functions.
>+As a result, when patching a static function, all its callers need to be
>+patches as well.

"Typo: "patches" should be "patched", but I'd suggest "are impacted"
here too.

>+In addition to all the flags that -flive-patching=inline-clone disables,
>+@option{-flive-patching=inline-only-static} disables the following additional
>+optimization flags:
>+@gccoptlist{-fipa-cp-clone  -fipa-sra  -fpartial-inlining  -fipa-cp}
>+
>+@end table
>+
>+When -flive-patching specified without any value, the default value
>+is "inline-clone".

This should use @option{} and @var{} and is missing the word "is".

>+This flag is disabled by default.
>+
>+Note that -flive-patching is not supported with link-time optimizer.

s/optimizer./optimization/

>+(@option{-flto}).
>+
> @item -fisolate-erroneous-paths-dereference
> @opindex fisolate-erroneous-paths-dereference
> Detect paths that trigger erroneous or undefined behavior due to

The attached patch makes some of these changes, but I'd like to know
if my changes preserve the intended meaning.


[-- Attachment #2: patch.txt --]
[-- Type: text/x-patch, Size: 2843 bytes --]

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 73a7789d879..1e9f0fa7230 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -9367,7 +9367,7 @@ This flag is enabled by default at @option{-O2} and @option{-Os}.
 
 @item -flive-patching=@var{level}
 @opindex flive-patching
-Control GCC's optimizations to provide a safe compilation for live-patching.
+Control GCC's optimizations to produce output suitable for live-patching.
 
 If the compiler's optimization uses a function's body or information extracted
 from its body to optimize/change another function, the latter is called an
@@ -9375,16 +9375,16 @@ impacted function of the former.  If a function is patched, its impacted
 functions should be patched too.
 
 The impacted functions are decided by the compiler's interprocedural
-optimizations.  For example, inlining a function into its caller, cloning
-a function and changing its caller to call this new clone, or extracting
-a function's pureness/constness information to optimize its direct or
-indirect callers, etc.
+optimizations.  For example, a caller is impacted when inlining a function
+into its caller,
+cloning a function and changing its caller to call this new clone,
+or extracting a function's pureness/constness information to optimize
+its direct or indirect callers, etc.
 
 Usually, the more IPA optimizations enabled, the larger the number of
 impacted functions for each function.  In order to control the number of
-impacted functions and computed the list of impacted function easily,
-we provide control to partially enable IPA optimizations on two different
-levels.
+impacted functions and more easily compute the list of impacted function,
+IPA optimizations can be partially enabled at two different levels.
 
 The @var{level} argument should be one of the following:
 
@@ -9407,21 +9407,22 @@ callers need to be patched as well.
 
 Only enable inlining of static functions.
 As a result, when patching a static function, all its callers need to be
-patches as well.
+patched as well.
 
-In addition to all the flags that -flive-patching=inline-clone disables,
+In addition to all the flags that @option{-flive-patching=inline-clone}
+disables,
 @option{-flive-patching=inline-only-static} disables the following additional
 optimization flags:
 @gccoptlist{-fipa-cp-clone  -fipa-sra  -fpartial-inlining  -fipa-cp}
 
 @end table
 
-When -flive-patching specified without any value, the default value
-is "inline-clone".
+When @option{-flive-patching} is specified without any value, the default value
+is @var{inline-clone}.
 
 This flag is disabled by default.
 
-Note that -flive-patching is not supported with link-time optimizer.
+Note that @option{-flive-patching} is not supported with link-time optimization
 (@option{-flto}).
 
 @item -fisolate-erroneous-paths-dereference

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

[Qing Zhao]

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  -fipa-reference  -fipa-reference-addressable @gol
>> -fipa-stack-alignment  -fipa-icf  -fira-algorithm=@var{algorithm} @gol
>> +-flive-patching=@var{level} @gol
>> -fira-region=@var{region}  -fira-hoist-pressure @gol
>> -fira-loop-pressure  -fno-ira-share-save-slots @gol
>> -fno-ira-share-spill-slots @gol
>> @@ -9045,6 +9046,65 @@ equivalences that are found only by GCC and equivalences found only by Gold.
>> This flag is enabled by default at @option{-O2} and @option{-Os}.
>> +@item -flive-patching=@var{level}
>> +@opindex flive-patching
>> +Control GCC's optimizations to provide a safe compilation for live-patching.
> 
> "provide a safe compilation" isn't very clear to me. I don't know what
> it means to "provide a compilation", let alone a safe one.
> 
> Could we say something like "Control GCC’s optimizations to produce
> output suitable for live-patching.” ?

yes, this is better.

> 
> 
>> +If the compiler's optimization uses a function's body or information extracted
>> +from its body to optimize/change another function, the latter is called an
>> +impacted function of the former.  If a function is patched, its impacted
>> +functions should be patched too.
>> +
>> +The impacted functions are decided by the compiler's interprocedural
> 
> decided or determined?
determined is better.

> 
>> +optimizations.  For example, inlining a function into its caller, cloning
>> +a function and changing its caller to call this new clone, or extracting
>> +a function's pureness/constness information to optimize its direct or
>> +indirect callers, etc.
> 
> I don't know what the second sentence is saying. I can read it two
> different ways:
> 
> 1) Those are examples of interprocedural optimizations which
> participate in the decision making, but the actual details of how the
> decisions are made are not specified here.
> 
> 2) Performing those optimizations causes a function to be impacted.
> 
> If 1) is the intended meaning, then I think it should say "For
> example, <INS>when</INS> inlining a function into its caller, ..."
> 
> If 2) is the intended meaning, then I think it should say "For
> example, <INS>a caller is impacted when</INS> inlining a function
> into its caller …".

2) is the intended meaining.

> 
> Does either of those suggestions match the intended meaning? Or do you
> have a better way to rephrase it?
> 
>> +Usually, the more IPA optimizations enabled, the larger the number of
>> +impacted functions for each function.  In order to control the number of
>> +impacted functions and computed the list of impacted function easily,
> 
> Should be "and more easily compute the list of impacted functions”.

this is good.
> 
>> +we provide control to partially enable IPA optimizations on two different
>> +levels.
> 
> We don't usually say "we provide" like this. I suggest simply "IPA
> optimizations can be partially enabled at two different levels.”

Okay.
> 
>> +
>> +The @var{level} argument should be one of the following:
>> +
>> +@table @samp
>> +
>> +@item inline-clone
>> +
>> +Only enable inlining and cloning optimizations, which includes inlining,
>> +cloning, interprocedural scalar replacement of aggregates and partial inlining.
>> +As a result, when patching a function, all its callers and its clones'
>> +callers need to be patched as well.
> 
> Since you've defined the term "impacted" could this just say "all its
> callers and its clones' callers are impacted.”?

I think that the following might be better:

when patching a function, all its callers and its clones’ callers are impacted, therefore need to be patched as well.

> 
>> +@option{-flive-patching=inline-clone} disables the following optimization flags:
>> +@gccoptlist{-fwhole-program  -fipa-pta  -fipa-reference  -fipa-ra @gol
>> +-fipa-icf  -fipa-icf-functions  -fipa-icf-variables @gol
>> +-fipa-bit-cp  -fipa-vrp  -fipa-pure-const  -fipa-reference-addressable @gol
>> +-fipa-stack-alignment}
>> +
>> +@item inline-only-static
>> +
>> +Only enable inlining of static functions.
>> +As a result, when patching a static function, all its callers need to be
>> +patches as well.
> 
> "Typo: "patches" should be "patched", but I'd suggest "are impacted"
> here too.

Okay.
> 
>> +In addition to all the flags that -flive-patching=inline-clone disables,
>> +@option{-flive-patching=inline-only-static} disables the following additional
>> +optimization flags:
>> +@gccoptlist{-fipa-cp-clone  -fipa-sra  -fpartial-inlining  -fipa-cp}
>> +
>> +@end table
>> +
>> +When -flive-patching specified without any value, the default value
>> +is "inline-clone".
> 
> This should use @option{} and @var{} and is missing the word "is”.
Okay.
> 
>> +This flag is disabled by default.
>> +
>> +Note that -flive-patching is not supported with link-time optimizer.
> 
> s/optimizer./optimization/
Okay.
> 
>> +(@option{-flto}).
>> +
>> @item -fisolate-erroneous-paths-dereference
>> @opindex fisolate-erroneous-paths-dereference
>> Detect paths that trigger erroneous or undefined behavior due to
> 
> The attached patch makes some of these changes, but I'd like to know
> if my changes preserve the intended meaning.

the changes in the patch looks good to me.

thanks a lot.

Qing
> 
> <patch.txt>

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

[Jonathan Wakely]

[-- Attachment #1: Type: text/plain, Size: 5808 bytes --]

On 10/04/19 13:55 -0500, Qing Zhao wrote:
>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  -fipa-reference  -fipa-reference-addressable @gol
>>> -fipa-stack-alignment  -fipa-icf  -fira-algorithm=@var{algorithm} @gol
>>> +-flive-patching=@var{level} @gol
>>> -fira-region=@var{region}  -fira-hoist-pressure @gol
>>> -fira-loop-pressure  -fno-ira-share-save-slots @gol
>>> -fno-ira-share-spill-slots @gol
>>> @@ -9045,6 +9046,65 @@ equivalences that are found only by GCC and equivalences found only by Gold.
>>> This flag is enabled by default at @option{-O2} and @option{-Os}.
>>> +@item -flive-patching=@var{level}
>>> +@opindex flive-patching
>>> +Control GCC's optimizations to provide a safe compilation for live-patching.
>>
>> "provide a safe compilation" isn't very clear to me. I don't know what
>> it means to "provide a compilation", let alone a safe one.
>>
>> Could we say something like "Control GCC’s optimizations to produce
>> output suitable for live-patching.” ?
>
>yes, this is better.
>
>>
>>
>>> +If the compiler's optimization uses a function's body or information extracted
>>> +from its body to optimize/change another function, the latter is called an
>>> +impacted function of the former.  If a function is patched, its impacted
>>> +functions should be patched too.
>>> +
>>> +The impacted functions are decided by the compiler's interprocedural
>>
>> decided or determined?
>determined is better.
>
>>
>>> +optimizations.  For example, inlining a function into its caller, cloning
>>> +a function and changing its caller to call this new clone, or extracting
>>> +a function's pureness/constness information to optimize its direct or
>>> +indirect callers, etc.
>>
>> I don't know what the second sentence is saying. I can read it two
>> different ways:
>>
>> 1) Those are examples of interprocedural optimizations which
>> participate in the decision making, but the actual details of how the
>> decisions are made are not specified here.
>>
>> 2) Performing those optimizations causes a function to be impacted.
>>
>> If 1) is the intended meaning, then I think it should say "For
>> example, <INS>when</INS> inlining a function into its caller, ..."
>>
>> If 2) is the intended meaning, then I think it should say "For
>> example, <INS>a caller is impacted when</INS> inlining a function
>> into its caller …".
>
>2) is the intended meaining.
>
>>
>> Does either of those suggestions match the intended meaning? Or do you
>> have a better way to rephrase it?
>>
>>> +Usually, the more IPA optimizations enabled, the larger the number of
>>> +impacted functions for each function.  In order to control the number of
>>> +impacted functions and computed the list of impacted function easily,
>>
>> Should be "and more easily compute the list of impacted functions”.
>
>this is good.
>>
>>> +we provide control to partially enable IPA optimizations on two different
>>> +levels.
>>
>> We don't usually say "we provide" like this. I suggest simply "IPA
>> optimizations can be partially enabled at two different levels.”
>
>Okay.
>>
>>> +
>>> +The @var{level} argument should be one of the following:
>>> +
>>> +@table @samp
>>> +
>>> +@item inline-clone
>>> +
>>> +Only enable inlining and cloning optimizations, which includes inlining,
>>> +cloning, interprocedural scalar replacement of aggregates and partial inlining.
>>> +As a result, when patching a function, all its callers and its clones'
>>> +callers need to be patched as well.
>>
>> Since you've defined the term "impacted" could this just say "all its
>> callers and its clones' callers are impacted.”?
>
>I think that the following might be better:
>
>when patching a function, all its callers and its clones’ callers are impacted, therefore need to be patched as well.

Agreed.

>>
>>> +@option{-flive-patching=inline-clone} disables the following optimization flags:
>>> +@gccoptlist{-fwhole-program  -fipa-pta  -fipa-reference  -fipa-ra @gol
>>> +-fipa-icf  -fipa-icf-functions  -fipa-icf-variables @gol
>>> +-fipa-bit-cp  -fipa-vrp  -fipa-pure-const  -fipa-reference-addressable @gol
>>> +-fipa-stack-alignment}
>>> +
>>> +@item inline-only-static
>>> +
>>> +Only enable inlining of static functions.
>>> +As a result, when patching a static function, all its callers need to be
>>> +patches as well.
>>
>> "Typo: "patches" should be "patched", but I'd suggest "are impacted"
>> here too.
>
>Okay.
>>
>>> +In addition to all the flags that -flive-patching=inline-clone disables,
>>> +@option{-flive-patching=inline-only-static} disables the following additional
>>> +optimization flags:
>>> +@gccoptlist{-fipa-cp-clone  -fipa-sra  -fpartial-inlining  -fipa-cp}
>>> +
>>> +@end table
>>> +
>>> +When -flive-patching specified without any value, the default value
>>> +is "inline-clone".
>>
>> This should use @option{} and @var{} and is missing the word "is”.
>Okay.
>>
>>> +This flag is disabled by default.
>>> +
>>> +Note that -flive-patching is not supported with link-time optimizer.
>>
>> s/optimizer./optimization/
>Okay.
>>
>>> +(@option{-flto}).
>>> +
>>> @item -fisolate-erroneous-paths-dereference
>>> @opindex fisolate-erroneous-paths-dereference
>>> Detect paths that trigger erroneous or undefined behavior due to
>>
>> The attached patch makes some of these changes, but I'd like to know
>> if my changes preserve the intended meaning.
>
>the changes in the patch looks good to me.
>
>thanks a lot.

Thanks!

I've attached an updated patch with your suggestions.

Reviewers, is this OK for trunk?



[-- Attachment #2: patch.txt --]
[-- Type: text/x-patch, Size: 3854 bytes --]

commit 0b9a201fb80fb1e708d83566df50f1555cf80e10
Author: nickc <nickc@138bc75d-0d04-0410-961f-82ee72b054a4>
Date:   Wed Apr 10 14:44:47 2019 +0000

    Clarify documentation for -flive-patching
    
            * doc/invoke.texi (Optimize Options): Clarify -flive-patching docs.

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 755b9f754a1..3a88d8db157 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -9367,24 +9367,24 @@ This flag is enabled by default at @option{-O2} and @option{-Os}.
 
 @item -flive-patching=@var{level}
 @opindex flive-patching
-Control GCC's optimizations to provide a safe compilation for live-patching.
+Control GCC's optimizations to produce output suitable for live-patching.
 
 If the compiler's optimization uses a function's body or information extracted
 from its body to optimize/change another function, the latter is called an
 impacted function of the former.  If a function is patched, its impacted
 functions should be patched too.
 
-The impacted functions are decided by the compiler's interprocedural
-optimizations.  For example, inlining a function into its caller, cloning
-a function and changing its caller to call this new clone, or extracting
-a function's pureness/constness information to optimize its direct or
-indirect callers, etc.
+The impacted functions are determined by the compiler's interprocedural
+optimizations.  For example, a caller is impacted when inlining a function
+into its caller,
+cloning a function and changing its caller to call this new clone,
+or extracting a function's pureness/constness information to optimize
+its direct or indirect callers, etc.
 
 Usually, the more IPA optimizations enabled, the larger the number of
 impacted functions for each function.  In order to control the number of
-impacted functions and computed the list of impacted function easily,
-we provide control to partially enable IPA optimizations on two different
-levels.
+impacted functions and more easily compute the list of impacted function,
+IPA optimizations can be partially enabled at two different levels.
 
 The @var{level} argument should be one of the following:
 
@@ -9395,7 +9395,7 @@ The @var{level} argument should be one of the following:
 Only enable inlining and cloning optimizations, which includes inlining,
 cloning, interprocedural scalar replacement of aggregates and partial inlining.
 As a result, when patching a function, all its callers and its clones'
-callers need to be patched as well.
+callers are impacted, therefore need to be patched as well.
 
 @option{-flive-patching=inline-clone} disables the following optimization flags:
 @gccoptlist{-fwhole-program  -fipa-pta  -fipa-reference  -fipa-ra @gol
@@ -9406,22 +9406,23 @@ callers need to be patched as well.
 @item inline-only-static
 
 Only enable inlining of static functions.
-As a result, when patching a static function, all its callers need to be
-patches as well.
+As a result, when patching a static function, all its callers are impacted
+and so need to be patched as well.
 
-In addition to all the flags that -flive-patching=inline-clone disables,
+In addition to all the flags that @option{-flive-patching=inline-clone}
+disables,
 @option{-flive-patching=inline-only-static} disables the following additional
 optimization flags:
 @gccoptlist{-fipa-cp-clone  -fipa-sra  -fpartial-inlining  -fipa-cp}
 
 @end table
 
-When -flive-patching specified without any value, the default value
-is "inline-clone".
+When @option{-flive-patching} is specified without any value, the default value
+is @var{inline-clone}.
 
 This flag is disabled by default.
 
-Note that -flive-patching is not supported with link-time optimizer.
+Note that @option{-flive-patching} is not supported with link-time optimization
 (@option{-flto}).
 
 @item -fisolate-erroneous-paths-dereference

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

[Richard Biener]

On Wed, Apr 10, 2019 at 9:49 PM Jonathan Wakely <jwakely@redhat.com> wrote:
>
> On 10/04/19 13:55 -0500, Qing Zhao wrote:
> >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  -fipa-reference  -fipa-reference-addressable @gol
> >>> -fipa-stack-alignment  -fipa-icf  -fira-algorithm=@var{algorithm} @gol
> >>> +-flive-patching=@var{level} @gol
> >>> -fira-region=@var{region}  -fira-hoist-pressure @gol
> >>> -fira-loop-pressure  -fno-ira-share-save-slots @gol
> >>> -fno-ira-share-spill-slots @gol
> >>> @@ -9045,6 +9046,65 @@ equivalences that are found only by GCC and equivalences found only by Gold.
> >>> This flag is enabled by default at @option{-O2} and @option{-Os}.
> >>> +@item -flive-patching=@var{level}
> >>> +@opindex flive-patching
> >>> +Control GCC's optimizations to provide a safe compilation for live-patching.
> >>
> >> "provide a safe compilation" isn't very clear to me. I don't know what
> >> it means to "provide a compilation", let alone a safe one.
> >>
> >> Could we say something like "Control GCC’s optimizations to produce
> >> output suitable for live-patching.” ?
> >
> >yes, this is better.
> >
> >>
> >>
> >>> +If the compiler's optimization uses a function's body or information extracted
> >>> +from its body to optimize/change another function, the latter is called an
> >>> +impacted function of the former.  If a function is patched, its impacted
> >>> +functions should be patched too.
> >>> +
> >>> +The impacted functions are decided by the compiler's interprocedural
> >>
> >> decided or determined?
> >determined is better.
> >
> >>
> >>> +optimizations.  For example, inlining a function into its caller, cloning
> >>> +a function and changing its caller to call this new clone, or extracting
> >>> +a function's pureness/constness information to optimize its direct or
> >>> +indirect callers, etc.
> >>
> >> I don't know what the second sentence is saying. I can read it two
> >> different ways:
> >>
> >> 1) Those are examples of interprocedural optimizations which
> >> participate in the decision making, but the actual details of how the
> >> decisions are made are not specified here.
> >>
> >> 2) Performing those optimizations causes a function to be impacted.
> >>
> >> If 1) is the intended meaning, then I think it should say "For
> >> example, <INS>when</INS> inlining a function into its caller, ..."
> >>
> >> If 2) is the intended meaning, then I think it should say "For
> >> example, <INS>a caller is impacted when</INS> inlining a function
> >> into its caller …".
> >
> >2) is the intended meaining.
> >
> >>
> >> Does either of those suggestions match the intended meaning? Or do you
> >> have a better way to rephrase it?
> >>
> >>> +Usually, the more IPA optimizations enabled, the larger the number of
> >>> +impacted functions for each function.  In order to control the number of
> >>> +impacted functions and computed the list of impacted function easily,
> >>
> >> Should be "and more easily compute the list of impacted functions”.
> >
> >this is good.
> >>
> >>> +we provide control to partially enable IPA optimizations on two different
> >>> +levels.
> >>
> >> We don't usually say "we provide" like this. I suggest simply "IPA
> >> optimizations can be partially enabled at two different levels.”
> >
> >Okay.
> >>
> >>> +
> >>> +The @var{level} argument should be one of the following:
> >>> +
> >>> +@table @samp
> >>> +
> >>> +@item inline-clone
> >>> +
> >>> +Only enable inlining and cloning optimizations, which includes inlining,
> >>> +cloning, interprocedural scalar replacement of aggregates and partial inlining.
> >>> +As a result, when patching a function, all its callers and its clones'
> >>> +callers need to be patched as well.
> >>
> >> Since you've defined the term "impacted" could this just say "all its
> >> callers and its clones' callers are impacted.”?
> >
> >I think that the following might be better:
> >
> >when patching a function, all its callers and its clones’ callers are impacted, therefore need to be patched as well.
>
> Agreed.
>
> >>
> >>> +@option{-flive-patching=inline-clone} disables the following optimization flags:
> >>> +@gccoptlist{-fwhole-program  -fipa-pta  -fipa-reference  -fipa-ra @gol
> >>> +-fipa-icf  -fipa-icf-functions  -fipa-icf-variables @gol
> >>> +-fipa-bit-cp  -fipa-vrp  -fipa-pure-const  -fipa-reference-addressable @gol
> >>> +-fipa-stack-alignment}
> >>> +
> >>> +@item inline-only-static
> >>> +
> >>> +Only enable inlining of static functions.
> >>> +As a result, when patching a static function, all its callers need to be
> >>> +patches as well.
> >>
> >> "Typo: "patches" should be "patched", but I'd suggest "are impacted"
> >> here too.
> >
> >Okay.
> >>
> >>> +In addition to all the flags that -flive-patching=inline-clone disables,
> >>> +@option{-flive-patching=inline-only-static} disables the following additional
> >>> +optimization flags:
> >>> +@gccoptlist{-fipa-cp-clone  -fipa-sra  -fpartial-inlining  -fipa-cp}
> >>> +
> >>> +@end table
> >>> +
> >>> +When -flive-patching specified without any value, the default value
> >>> +is "inline-clone".
> >>
> >> This should use @option{} and @var{} and is missing the word "is”.
> >Okay.
> >>
> >>> +This flag is disabled by default.
> >>> +
> >>> +Note that -flive-patching is not supported with link-time optimizer.
> >>
> >> s/optimizer./optimization/
> >Okay.
> >>
> >>> +(@option{-flto}).
> >>> +
> >>> @item -fisolate-erroneous-paths-dereference
> >>> @opindex fisolate-erroneous-paths-dereference
> >>> Detect paths that trigger erroneous or undefined behavior due to
> >>
> >> The attached patch makes some of these changes, but I'd like to know
> >> if my changes preserve the intended meaning.
> >
> >the changes in the patch looks good to me.
> >
> >thanks a lot.
>
> Thanks!
>
> I've attached an updated patch with your suggestions.
>
> Reviewers, is this OK for trunk?

OK (it's an improvement at least).

Richard.

>

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

[Miroslav Benes]

[-- Attachment #1: Type: text/plain, Size: 4484 bytes --]

On Tue, 13 Nov 2018, Qing Zhao wrote:

> Hi,
> 
> > On Nov 13, 2018, at 1:18 PM, Miroslav Benes <mbenes@suse.cz> 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 multiple-level control on how many of the
> >>     optimizations are enabled by users' request.  The LEVEL argument
> >>     should be one of the following:
> >> 
> >>     'inline-only-static'
> >> 
> >>          Only enable inlining of static functions, disable all other
> >>          ipa optimizations/analyses.  As a result, when patching a
> >>          static routine, all its callers need to be patches as well.
> >> 
> >>     'inline-clone'
> >> 
> >>          Only enable inlining and all optimizations that internally
> >>          create clone, for example, cloning, ipa-sra, partial inlining,
> >>          etc.; disable all other ipa optimizations/analyses.  As a
> >>          result, when patching a routine, all its callers and its
> >>          clones' callers need to be patched as well.
> > 
> > Based on our previous discussion I assume that "clone" optimizations are 
> > safe (for LP) and the others are not. Anyway I'd welcome a note mentioning 
> > that disabled optimizations are dangerous for LP.
> 
> actually, I don’t think that those disabled optimizations are “dangerous” for live-patching. one of the major reasons we disable them
> is because that currently the compiler does NOT provide a good way to compute the impacted function list for those optimizations.
> therefore, we disable them at this time. 
> 
> many of them could be enabled too if the compiler can report the impacted function list accurately in the future.

Yes, you can formulate it like that. On the other hand, I (we) have always 
tried to keep a set of patched functions as small as possible. So some 
cost-benefit analysis would have to be done. However, that's another 
problem and we can discuss it later.

> > 
> > I know it may be the same for you, but it is not for me as a GCC user. 
> > "internally create clone" sounds very... well, internal. It does not 
> > describe the option much for ordinary user whow has no knowledge about GCC 
> > internals.
> > 
> > So could you rephrase it a bit, please?
> 
> I tried to make this clear. please see the following:
> 
> '-flive-patching=LEVEL'
>      Control GCC's optimizations to provide a safe compilation for
>      live-patching.
> 
>      If the compiler's optimization uses a function's body or
>      information extracted from its body to optimize/change another
>      function, the latter is called an impacted function of the former.
>      If a function is patched, its impacted functions should be patched
>      too.
> 
>      The impacted functions are decided by the compiler's
>      interprocedural optimizations.  For example, inlining a function
>      into its caller, cloning a function and changing its caller to call
>      this new clone, or extracting a function's pureness/constness
>      information to optimize its direct or indirect callers, etc.
> 
>      Usually, the more ipa optimizations enabled, the larger the number
>      of impacted functions for each function.  In order to control the
>      number of impacted functions and computed the list of impacted
>      function easily, we provide control to partially enable ipa
>      optimizations on two different levels.
> 
>      The LEVEL argument should be one of the following:
> 
>      'inline-only-static'
> 
>           Only enable inlining of static functions, disable all other
>           interprocedural optimizations/analyses.  As a result, when
>           patching a static routine, all its callers need to be patches
>           as well.
> 
>      'inline-clone'
> 
>           Only enable inlining and cloning optimizations, which includes
>           inlining, cloning, interprocedural scalar replacement of
>           aggregates and partial inlining.  Disable all other
>           interprocedural optimizations/analyses.  As a result, when
>           patching a routine, all its callers and its clones' callers
>           need to be patched as well.
> 
>      When -flive-patching specified without any value, the default value
>      is "inline-clone".
> 
>      This flag is disabled by default.

Sounds better. Thanks.

Miroslav

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

[Martin Liška]

On 11/10/18 6:03 PM, Jan Hubicka 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.
>>
>>>
>>> 1. do we still need new options to disable the following:
>>>    A. unreachable code/variable removal? 
>>
>> I hope it's guarded with newly added option -fipa-reference-addressable. Correct me
>> if I'm wrong.
> 
> No, unreachable code removal is still independent (we track all
> references and can remove variable with address taken)
> If you really want to keep all the symbols, you probably can mark
> everything as force_output like flag_keep_inline functions is
> implemented.  I am not sure how practical it would be though.

I see, that's probably not practical to start using a function/variable that
wasn't used before a live patch.

Martin

> 
> Honza
>>
>>>    B. Visibility changes with -flto and/or -fwhole-program?
>>
>> The options are not used in linux kernel, thus I didn't consider.
>>
>>>
>>> 2. for this new patch, could you please explain a little bit more on the problem?
>>
>> We want to enable a single option that will disable all possible (and future) optimizations
>> that influence live patching.
>>
>> Martin
>>
>>>
>>> Thanks.
>>>
>>> Qing
>>>
>>>> On Nov 9, 2018, at 9:33 AM, Martin Liška <mliska@suse.cz> wrote:
>>>>
>>>> Hi.
>>>>
>>>> After I added 2 new options, I would like to include a new master option.
>>>> It's minimal version which only disables optimizations that we are aware of
>>>> and can potentially cause problems for live-patching.
>>>>
>>>> Martin
>>>> <0001-Come-up-with-fvectorized-functions.patch>
>>>
>>

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

[Bernhard Reutner-Fischer]

On 9 November 2018 16:33:22 CET, "Martin Liška" <mliska@suse.cz> wrote:
>Hi.
>
>After I added 2 new options, I would like to include a new master
>option.
>It's minimal version which only disables optimizations that we are
>aware of
>and can potentially cause problems for live-patching.

I think you attached the wrong patch, AFAICS you attached the gfortran vectorized_builtins patch..

thanks,

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

[Martin Liška]

[-- Attachment #1: Type: text/plain, Size: 48 bytes --]

Hi.

Sorry for attaching a wrong patch.

Martin

[-- Attachment #2: 0001-Come-up-with-flive-patching-master-option.patch --]
[-- Type: text/x-patch, Size: 2865 bytes --]

From 7d3887b1b24901eca69614e601b6e8f36e5c86eb Mon Sep 17 00:00:00 2001
From: marxin <mliska@suse.cz>
Date: Fri, 9 Nov 2018 16:28:07 +0100
Subject: [PATCH] Come up with -flive-patching master option.

gcc/ChangeLog:

2018-11-09  Martin Liska  <mliska@suse.cz>

	* common.opt: Add -flive-patching option.
	* opts.c (disable_live_patching_related_optimizations): New
	function where we disable all optimizations that are potentially
	dangerous for live patching.
	(common_handle_option): Call the function.
---
 gcc/common.opt |  4 ++++
 gcc/opts.c     | 31 +++++++++++++++++++++++++++++++
 2 files changed, 35 insertions(+)

diff --git a/gcc/common.opt b/gcc/common.opt
index 98e8eb03ef3..475b667f26b 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -2156,6 +2156,10 @@ flive-range-shrinkage
 Common Report Var(flag_live_range_shrinkage) Init(0) Optimization
 Relief of register pressure through live range shrinkage.
 
+flive-patching
+Common Report Var(flag_live_patching) Init(0) Optimization
+Perform only safe IPA transformations for live patching.
+
 frename-registers
 Common Report Var(flag_rename_registers) Init(2) Optimization
 Perform a register renaming optimization pass.
diff --git a/gcc/opts.c b/gcc/opts.c
index e21967ba84d..dd0c24ac2f9 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -1548,6 +1548,33 @@ enable_fdo_optimizations (struct gcc_options *opts,
     opts->x_flag_tree_loop_distribute_patterns = value;
 }
 
+/* Disable IPA optimization that are not safe for live patching.  */
+
+static void
+disable_live_patching_related_optimizations (gcc_options *opts,
+					     gcc_options *opts_set)
+{
+  if (!opts_set->x_flag_ipa_icf_functions)
+    opts->x_flag_ipa_icf_functions = 0;
+
+  if (!opts_set->x_flag_ipa_icf)
+      opts->x_flag_ipa_icf = 0;
+  if (!opts_set->x_flag_ipa_icf_variables)
+      opts->x_flag_ipa_icf_variables = 0;
+  if (!opts_set->x_flag_ipa_pure_const)
+      opts->x_flag_ipa_pure_const = 0;
+  if (!opts_set->x_flag_ipa_pta)
+      opts->x_flag_ipa_pta = 0;
+  if (!opts_set->x_flag_ipa_reference)
+      opts->x_flag_ipa_reference = 0;
+  if (!opts_set->x_flag_ipa_reference_addressable)
+      opts->x_flag_ipa_reference_addressable = 0;
+  if (!opts_set->x_flag_ipa_stack_alignment)
+      opts->x_flag_ipa_stack_alignment = 0;
+  if (!opts_set->x_flag_ipa_ra)
+      opts->x_flag_ipa_ra = 0;
+}
+
 /* -f{,no-}sanitize{,-recover}= suboptions.  */
 const struct sanitizer_opts_s sanitizer_opts[] =
 {
@@ -2266,6 +2293,10 @@ common_handle_option (struct gcc_options *opts,
 	(&opts->x_flag_instrument_functions_exclude_files, arg);
       break;
 
+    case OPT_flive_patching:
+      if (value)
+	disable_live_patching_related_optimizations (opts, opts_set);
+
     case OPT_fmessage_length_:
       pp_set_line_maximum_length (dc->printer, value);
       diagnostic_set_caret_max_width (dc, value);
-- 
2.19.1

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

[Martin Jambor]

Hi,

On Wed, Oct 03 2018, 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.
>
>  We have transformations that are modeled as clonning, which are
>   - inlining  (can't be disabled completely because of always inline, but -fno-inline
>     does most of stuff)
>   - cloning (disabled via -fno-ipa-cp)
>   - ipa-sra (-fno-ipa-sra)
>   - splitting (-fno-partial-inlining)
>  These should play well with Martin's tracking code
>
>  We propagate info about side effects of function:
>   - function attribute discovery (pure, const, nothrow, malloc)
>     Some of this can be disabled by -fno-ipa-pure-const, but not all
>     of it.  Nothrow does not have flag but it is obviously not a concern
>     for C++
>   - 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)
>   - inter-procedural register allocation (-fno-ipa-ra)

I was thinking a bit more about this and recalled that not all stuff
that IPA-CP nowadays does involves creating clones, so we have to add
also:
  - -fno-ipa-bit-cp, and
  - -fno-ipa-vrp.

These two just record info in the parameters of *callees* of functions
from which it extracted info, without any cloning involved.  Both were
introduced in GCC 7.

Thanks,

Martin

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

[Qing Zhao]

> On Oct 3, 2018, at 4:04 AM, Jan Hubicka <hubicka@ucw.cz> 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.
> 
> We have transformations that are modeled as clonning, which are
>  - inlining  (can't be disabled completely because of always inline, but -fno-inline
>    does most of stuff)
>  - cloning (disabled via -fno-ipa-cp)
>  - ipa-sra (-fno-ipa-sra)
>  - splitting (-fno-partial-inlining)
> These should play well with Martin's tracking code

In addition to the above IPA transformations that cloned a routine, the following RTL transformation will clone a routine, too:

reorder-blocks-and-partition

this optimization will create .cold routines based on profiling feedback.

looks like that we also need to include this transformation into this category?

> 
> We propagate info about side effects of function:
>  - function attribute discovery (pure, const, nothrow, malloc)
>    Some of this can be disabled by -fno-ipa-pure-const, but not all
>    of it.  Nothrow does not have flag but it is obviously not a concern
>    for C++
>  - 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)
>  - inter-procedural register allocation (-fno-ipa-ra)


> 
> We perform discovery of functions/variables with no address taken and
> optimizations that are not valid otherwise such as duplicating them
> or doing skipping them for alias analysis (no flag to disable)
> 
> Identical code folding merges function bodies that are semanticaly equivalent
> and thus one can't patch one without patching another, -fno-ipa-icf
> 
> Unreachable code/variable removal may be concern too (no flag to disable)
> 
> Write only global variable discovery (no flag to dosable)
> 
> Visibility changes with -flto and/or -fwhole-program
> 
> We also have profile propagation (discovery of cuntions used only in cold regions,
> but that I guess is only performance issue not correctness)
> No flag to disable

are all the above analyzes guarded by AVAIL_INTERPOSABLE right now?
If NOT, should they be guarded by AVAIL_INTERPOSABLE?

Qing

> 
> Honza
> 
>> 
>> Martin
>> 
>>> 
>>> thanks.
>>> 
>>> Qing
>>> 
>> 

Performance impact of disabling non-clone IPA optimizations for the Linux kernel (was: "GCC options for kernel live-patching")

[Nicolai Stange]

Hi,

let me summarize some results from performance comparisons of Linux
kernels compiled with and without certain IPA optimizations.

It's a slight abuse of this thread, but I think having the numbers might
perhaps give some useful insights on the potential costs associated with
the -flive-patching discussed here.

All kudos go to Giovanni Gherdovich from the SUSE Performance Team who
did all of the work presented below.

For a TL;DR, see the conclusion at the end of this email.

Martin Jambor <mjambor@suse.cz> writes:

> (this message is a part of the thread originating with
> https://gcc.gnu.org/ml/gcc-patches/2018-09/msg01018.html)
>
> We have just had a quick discussion with two upstream maintainers of
> Linux kernel live-patching about this and the key points were:
>
> 1. SUSE live-patch creators (and I assume all that use the upstream
>    live-patching method) use Martin Liska's (somewhat under-documented)
>    -fdump-ipa-clones option and a utility he wrote
>    (https://github.com/marxin/kgraft-analysis-tool) to deal with all
>    kinds of inlining, IPA-CP and generally all IPA optimizations that
>    internally create a clone.  The tool tells them what happened and
>    also lists all callers that need to be live-patched.
>
> 2. However, there is growing concern about other IPA analyses that do
>    not create a clone but still affect code generation in other
>    functions.  Kernel developers have identified and disabled IPA-RA but
>    there is more of them such as IPA-modref analysis, stack alignment
>    propagation and possibly quite a few others which extract information
>    from one function and use it a caller or perhaps even some
>    almost-unrelated functions (such as detection of read-only and
>    write-only static global variables).
>
>    The kernel live-patching community would welcome if GCC had an option
>    that could disable all such optimizations/analyses for which it
>    cannot provide a list of all affected functions (i.e. which ones need
>    to be live-patched if a particular function is).

AFAIU, the currently known IPA optimizations of this category are
(c.f. [1] and [2] from this thread):

 - -fipa-pure-const
 - -fipa-pta
 - -fipa-reference
 - -fipa-ra
 - -fipa-icf
 - -fipa-bit-cp
 - -fipa-vrp
 - and some others which might be problematic but currently can't get
   disabled on the cli:
   - stack alignment requirements
   - duplication of or skipping of alias analysis for
     functions/variables whose address is not taken (I don't know what
     that means, TBH).

Some time ago, Giovanni compared the performance of a kernel compiled with

 -fno-ipa-pure-const
 -fno-ipa-pta
 -fno-ipa-reference
 -fno-ipa-ra
 -fno-ipa-icf
 -fno-ipa-bit-cp
 -fno-ipa-vrp

plus (because I wasn't able to tell whether these are problematic in the
context of live patching)

 -fno-ipa-cp
 -fno-ipa-cp-clone
 -fno-ipa-profile
 -fno-ipa-sra

against a kernel compiled without any of these.

The kernel was a 4.12.14 one with additional patches on top.

The benchmarks had been performed on a smaller and on a bigger machine
each. Specs:
- single socket with a Xeon E3-1240 v5 (Skylake), 4 cores / 8 threads,
  32G of memory (UMA)
- 2 sockets with each one mounting a Xeon E5-2698 v4 (Broadwell) for a
  total of 40 cores / 80 threads and 528G of memory (NUMA)

You can find the results here:

  https://beta.suse.com/private/nstange/ggherdovich-no-ipa-results/dashboard.html

"laurel2" is the smaller machine, "hardy4" the bigger one.

The numbers presented in the dashboard are a relative measure of how the
no-ipa kernel was performing in comparison to the stock one. "1" means
no change, and, roughly speaking, each deviation by 0.01 from that value
corresponds to an overall performance change of 1%. Depending on the
benchmark, higher means better (e.g. for throughput) or vice versa
(e.g. for latencies). Some of the numbers are highlighted in green or
red. Green means that the no-ipa kernel performs better, red the
contrary.

The sockperf-{tcp,udp}-under-load results are spoiled due to outliers,
probably because of slow vs. fast paths. Please ignore.

(If you're interested in the detailed results, you can click on any of
 those accumulated numbers in the dashboard. Scroll down and you'll find
 some nice plots.)

For the overall outcome, let me quote Giovanni who summarized it nicely:

  What's left in red:

  * fsmark-threaded on laurel2 (skylake 8 cores), down 2%: if you look at the
    histograms of files created per seconds, there is never a clear winner
    between with and without IPA (except for the single-threaded case). Clean
    on hardy4.

  * sockperf-udp-throughput, hardy4: yep this one is statistically
    significant (in the plot you clearly see that the green dots are all
    below the yellow dots). 4% worst on average. Clean on the other machine.

  * tbench: this one is significant too (look at the histogram, no
    overlapping between the two distributions) but it's a curious one,
    because on the other machine is reversed (1% worse on the big hardy4, 4%
    better on the small laurel2).

  The other numbers don't change between the two kernels, or if they do the
  variance is large and you can't say much (large p-value).

[/quote end]

In conclusion, only a small subset of the tests peformed worse on the
no-ipa kernel and for those that did, the differences haven't been
really large in magnitude.

Thanks,

Nicolai

[1] 20181003090457.GJ57692@kam.mff.cuni.cz  from Jan Hubicka <hubicka@ucw.cz>
[2] ri65zyjti57.fsf@suse.cz  from Martin Jambor <mjambor@suse.cz>


>    I assume this is orthogonal to the proposed -finline-only-static
>    option, but the above approach seems superior in all respects.
>
> 3. The community would also like to be involved in these discussions,
>    and therefore I am adding live-patching@vger.kernel.org to CC.  On a
>    related note, they will also have a live-patching mini-summit at the
>    Linux Plumbers conference in Vancouver in November where they plan to
>    discuss what they would like GCC to provide.
>
> Thanks,
>
> Martin

-- 
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)

Re: Performance impact of disabling non-clone IPA optimizations for the Linux kernel (was: "GCC options for kernel live-patching")

[Jiri Kosina]

On Tue, 23 Oct 2018, Nicolai Stange wrote:

> let me summarize some results from performance comparisons of Linux
> kernels compiled with and without certain IPA optimizations.

Thanks a lot for the summary.

So, would it make sense to submit a patch upstream (with exactly this 
justification / explanation) that'd basically disable those optimizations 
for CONFIG_LIVEPATCH=y configs?

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: Performance impact of disabling non-clone IPA optimizations for the Linux kernel (was: "GCC options for kernel live-patching")

[Miroslav Benes]

On Wed, 24 Oct 2018, Jiri Kosina wrote:

> On Tue, 23 Oct 2018, Nicolai Stange wrote:
> 
> > let me summarize some results from performance comparisons of Linux
> > kernels compiled with and without certain IPA optimizations.
> 
> Thanks a lot for the summary.
> 
> So, would it make sense to submit a patch upstream (with exactly this 
> justification / explanation) that'd basically disable those optimizations 
> for CONFIG_LIVEPATCH=y configs?

It is premature in my opinion. I'd solve it on GCC side first, so that we 
have a new option which would cover everything (see the other emails in 
the thread). Then we can use it in the kernel for CONFIG_LIVEPATCH=y 
configs.

We could disable what is possible to disable even now but it would not 
solve everything and it is questionable if it is worth it then.

Miroslav

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

[Qing Zhao]

> On Sep 27, 2018, at 3:58 AM, Jan Hubicka <hubicka@ucw.cz> 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 other optimization will give up on these.
>> 
>> do you suggest that to set the global function as AVAIL_INTERPOSABLE when -finline-only-static 
>> is present? then we should avoid all issues?
> 
> It seems to be reasonable direction I think, because it is what really happens
> (well AVAIL_INTERPOSABLE still does not assume that the interposition will
> happen at runtime, but it is an approximation and we may introduce something like
> AVAIL_RUNTIME_INTERPOSABLE if there is need for better difference).
> I wonder if -finline-only-static is good name for the flag though, because it
> does a lot more than that.  Maybe something like -flive-patching?
> How much is this all tied to one particular implementation of the feature?

Yes, I like this idea. I will study a little more on this direction and report back.

Qing
> 
> Honza
>> 
>> Qing
>> 

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

[Qing Zhao]

> On Sep 26, 2018, at 12:16 PM, Jan Hubicka <hubicka@ucw.cz <mailto:hubicka@ucw.cz>> wrote:
> 
>>> 
>>> On Sep 26, 2018, at 10:06 AM, Jan Hubicka <hubicka@ucw.cz <mailto:hubicka@ucw.cz>> wrote:
>>> 
>>>> On Wed, Sep 26, 2018 at 10:45 AM, Jeff Law <law@redhat.com <mailto:law@redhat.com>> wrote:
>>>>> On 9/26/18 7:38 AM, Jason Merrill wrote:
>>>>>> On Wed, Sep 26, 2018 at 9:24 AM, Richard Biener <rguenther@suse.de <mailto:rguenther@suse.de>> wrote:
>>>>>>> IIRC he explicitely wanted 'static' not 'hidden' linkage.  Not sure
>>>>>>> what 'internal' would mean in this context.
>>>>>> 
>>>>>> I mean internal linkage as in the C and C++ standards.
>>>> 
>>>>> Since this is primarily for kernel hot patching, I think we're looking
>>>>> to restrict inlining to functions that have visibility limited to a
>>>>> compilation unit.
>>>> 
>>>> Right, which is internal linkage.
>>>> 
>>>> C11: "Within one translation unit, each declaration of an identifier
>>>> with internal linkage denotes the same object or function."
>>>> C++17: "When a name has internal linkage, the entity it denotes can be
>>>> referred to by names from other scopes in the same translation unit."
>>>> 
>>>> Or perhaps we want to say "not external linkage", i.e. !TREE_PUBLIC as
>>>> richi suggested.
>>> 
>>> I am not quite sure if we can relate visibility flags we have at this stage
>>> to visibility in source languge in very coherent way.  They change a lot with
>>> LTO and we may want to make this option incompatible with LTO, but even w/o
>>> we can turn function static that previously wasn’t.
>> 
>> Looks like both LTO and whole_program need to be made incompatible with -finline-only-static. 
>> from my study of the function “cgraph_externally_visible_p”, comdat functions can ONLY be turned into
>> static when either “in_lto_p” or “whole_program” is true. 
> 
> This is not quite the case, because, we can still clone them to static functions
> or derive fact about their side effects (such that information if they write/read
> memory, particular global var etc).  All this inter-procedural propagation
> is guarded by get_availability predicate returning at least AVAILABLE.

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 other optimization will give up on these.

do you suggest that to set the global function as AVAIL_INTERPOSABLE when -finline-only-static 
is present? then we should avoid all issues?

Qing


> Honza
>> 
>> 
>>> For example comdat that was cloned by IPA-SRA. See can_be_local_p and
>>> comdat_can_be_unshared_p predicates.  Similar problem happens to clones created
>>> by ipa-cp.
>>> 
>>> I guess we want to disable localization and cloning in this case as well.
>>> I wonder what else.
>> 
>> Yes, I think we should make -finline-only-static incompatible with cloning and tree-sra too.
>> 
>> Qing
>>> 
>>> Honza

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

[Qing Zhao]

> On Sep 26, 2018, at 9:45 AM, Jeff Law <law@redhat.com> wrote:
> 
> On 9/26/18 7:38 AM, Jason Merrill wrote:
>> On Wed, Sep 26, 2018 at 9:24 AM, Richard Biener <rguenther@suse.de> wrote:
>>> IIRC he explicitely wanted 'static' not 'hidden' linkage.  Not sure
>>> what 'internal' would mean in this context.
>> 
>> I mean internal linkage as in the C and C++ standards.
> Since this is primarily for kernel hot patching, I think we're looking
> to restrict inlining to functions that have visibility limited to a
> compilation unit.

Yes. that’s the intention.

-finline-only-static will ONLY inline functions that are visible within the current compilation unit.

Qing
> 
> Qing, can you confirm that either way?
> 
> Jeff

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

[Qing Zhao]

> On Sep 26, 2018, at 8:24 AM, Richard Biener <rguenther@suse.de> wrote:
> 
> On Wed, 26 Sep 2018, Jason Merrill wrote:
> 
>> On Fri, Sep 21, 2018 at 11:12 AM, Qing Zhao <qing.zhao@oracle.com> wrote:
>>> Hi, this is the 4th version of the patch.
>>> 
>>> mainly address Martin’s comments on some spelling issues.
>>> 
>>> I have tested the patch on both x86 and aarch64, no issue.
>>> 
>>> Okay for commit?
>>> 
>>> thanks.
>>> 
>>> Qing.
>>> 
>>> gcc/ChangeLog
>>> 
>>> +2018-09-20  Qing Zhao  <qing.zhao@oracle.com>
>>> +
>>> +       * cif-code.def (FUNCTION_EXTERN): New CIFCODE.
>>> +       * common.opt (-finline-only-static): New option.
>>> +       * doc/invoke.texi: Document -finline-only-static.
>>> +       * ipa-inline.c (can_inline_edge_p): Control inlining based on
>>> +       function's linkage.
>> 
>> I would suggest "internal" rather than "static" in general.  So
>> 
>> +    N_("function has external linkage when the user requests only"
>> +       " inlining functions with internal linkage"))
>> 
>> +Inline functions only if they have internal linkage.
>> 
>> +@item -finline-only-internal
>> +@opindex finline-only-internal
>> +By default, GCC inlines functions without considering their linkage.
>> +This flag guides the inliner to only inline functions with internal linkage.
>> +This option has any effect only when inlining itself is turned on by the
>> +-finline-functions or -finline-small-functions options.
>> 
>> This should also mention whether it applies to functions explicitly
>> declared inline; I assume it does not.
> 
> IIRC he explicitely wanted 'static' not 'hidden' linkage.

Yes.  that’s the intention. It will be very helpful to compile the application with ONLY inlining
STATIC functions for online-patching purpose. 

>  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 at depending on what we intend to do.

from the comments of callee->externally_visible in cgraph.h:

  /* Set when function is visible by other units.  */
  unsigned externally_visible : 1;

My understand of this “externally_visible” is:

this function is visible from other compilation units.

Is this correct?

> 
> What about 'static' functions with their address taken?
> 

such functions should still be inlined if -finline-only-static is specified. 

is there any issue with this?

> Note you shouldn't look at individual cgraph_node fields but use
> some of the accessors with more well-constrained semantics.
> Why are you not simply checking !TREE_PUBLIC?

Yes, looks like that TREE_PUBLIC(node->decl) might be better for this purpose.

> 
> Honza might be able to suggest one.

thanks.

Qing
> 
> Richard.

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

[Jan Hubicka]

> >  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 at depending on what we intend to do.
> 
> from the comments of callee->externally_visible in cgraph.h:
> 
>   /* Set when function is visible by other units.  */
>   unsigned externally_visible : 1;
> 
> My understand of this “externally_visible” is:
> 
> this function is visible from other compilation units.
> 
> Is this correct?

Yes, but the catch is that we may "localize" previously visible function into
invisible by clonning, see my previous email.
> > Note you shouldn't look at individual cgraph_node fields but use
> > some of the accessors with more well-constrained semantics.
> > Why are you not simply checking !TREE_PUBLIC?
> 
> Yes, looks like that TREE_PUBLIC(node->decl) might be better for this purpose.

externally_visible is better approximation, TREE_PUBLIC is false i.e. for
weakref aliases.  But we need to check places where externally visible functions
are turned to local.

What about comdats in general? What is the intended behaviour? If you prevent
inlining them completely, C++ programs will be very slow.
Also we still can analyze the body and derive some facts about them to drive
optimization (such as discovering that they are const/pure etc). Do we want
to disable this too?

Honza

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

[Qing Zhao]

> On Sep 26, 2018, at 11:02 AM, Jan Hubicka <hubicka@ucw.cz> 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 at depending on what we intend to do.
>> 
>> from the comments of callee->externally_visible in cgraph.h:
>> 
>>  /* Set when function is visible by other units.  */
>>  unsigned externally_visible : 1;
>> 
>> My understand of this “externally_visible” is:
>> 
>> this function is visible from other compilation units.
>> 
>> Is this correct?
> 
> Yes, but the catch is that we may "localize" previously visible function into
> invisible by clonning, see my previous email.

Yes, these are the cases that we need to take care carefully.

>>> Note you shouldn't look at individual cgraph_node fields but use
>>> some of the accessors with more well-constrained semantics.
>>> Why are you not simply checking !TREE_PUBLIC?
>> 
>> Yes, looks like that TREE_PUBLIC(node->decl) might be better for this purpose.
> 
> externally_visible is better approximation, TREE_PUBLIC is false i.e. for
> weakref aliases.  But we need to check places where externally visible functions
> are turned to local.

So, do you suggest to make all the optimizations that might turn external visible functions into local 
as incompatible with -finline-only-static?


(a possible list of such optimizations include cloning, ipa-cp, ipa-sra, etc?)

> 
> What about comdats in general? What is the intended behaviour? If you prevent
> inlining them completely, C++ programs will be very slow.
> Also we still can analyze the body and derive some facts about them to drive
> optimization (such as discovering that they are const/pure etc). Do we want
> to disable this too?

my current understanding of comdat functions is:  they are external visible initially, but under
some special situation, (for example, comdat_can_be_unshared_p + in_lto_p), they can 
be converted to local by the compiler. 

so, for most of the comdat functions, they are NOT inlined by the current implementation if -finline-only-static
is specified due to they are externally_visible.  

I am not sure whether it’s necessary to change this current behavior for comdat functions, I assume that most
of the applications for online patching are not written by C++,  not sure whether this assumption is reasonable or not?

any suggestion?

thanks.

Qing



> Honza