Re: [PATCH] options: Make -Ofast switch off -fsemantic-interposition
On Fri, Nov 19, 2021 at 9:55 AM Martin Jambor wrote: > > Hi, > > On Fri, Nov 19 2021, Jan Hubicka wrote: > >> > Hi, > >> > > >> > On Fri, Nov 12 2021, Martin Jambor wrote: > >> > > Hi, > >> > > > >> > > using -fno-semantic-interposition has been reported by various people > >> > > to bring about considerable speed up at the cost of strict compliance > >> > > to the ELF symbol interposition rules See for example > >> > > https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup > >> > > > >> > > As such I believe it should be implied by our -Ofast optimization > >> > > level, not only so that benchmarks that can benefit run faster, but > >> > > also so that people looking at -Ofast documentation for options that > >> > > could speed their programs find it. > >> > > > >> > > I have verified that with the following patch IPA-CP sees > >> > > flag_semantic_interposition set to zero at Ofast and that info and pdf > >> > > manual builds fine with the documentation change. I am bootstrapping > >> > > and testing it now in order to comply with submission criteria but I > >> > > don't think an Ofast change gets much tested. > >> > > > >> > > Assuming it passes, is the patch OK? (If it is, I will also add a note > >> > > about it in the "Caveats" section in gcc-12/changes.html of wwwdocs > >> > > after I commit the patch.) > >> > > > >> > > >> > Unfortunately, I was wrong, there are testcases which use the optimize > >> > attribute to switch a function to Ofast and those ICE because > >> > -fsemantic-interposition is not an optimization flag and only > >> > optimization flags can change in an optimize attribute (AFAIK, I only > >> > had a quick glance at the results). > >> > > >> > I am not sure what is the right way to tackle this, whether to set the > >> > flag at Ofast in some nonstandard way or make the flag an optimization > >> > flag - probably affecting function definitions, having it affect > >> > call-sites seems too fine-grained. I will try to discuss this on IRC on > >> > Monday (and hope such change is still doable early stage3). > >> > > >> > Sorry for posting this a bit prematurely, > >> > >> Hi, > >> > >> This patch turns flag_semantic_interposition to optimization option so > >> it can be enabled with per-function granuality. This is done by adding > >> the flag among visibility flags into the symbol table. This fixes the > >> behaviour on the testcase I added to testsuite. > >> > >> There are bugs where get_availability misbehaves on partitioned program. > >> We can also use the new flag to fix those, but I will do that > >> incrementally. > >> > >> The -Ofast change should be safe now. > > > > Also forgot to say it explicitly, the patch is OK, so please commit it. > > > > Thanks a lot for the enabling patch. I have committed mine after re-testing. > > Martin Perhaps reconsider https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100937 (configure: Add --enable-default-semantic-interposition)? Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572018.html I happen a write-up on https://maskray.me/blog/2021-05-09-fno-semantic-interposition -- 宋方睿
Re: [PATCH] options: Make -Ofast switch off -fsemantic-interposition
Hi, On Fri, Nov 19 2021, Jan Hubicka wrote: >> > Hi, >> > >> > On Fri, Nov 12 2021, Martin Jambor wrote: >> > > Hi, >> > > >> > > using -fno-semantic-interposition has been reported by various people >> > > to bring about considerable speed up at the cost of strict compliance >> > > to the ELF symbol interposition rules See for example >> > > https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup >> > > >> > > As such I believe it should be implied by our -Ofast optimization >> > > level, not only so that benchmarks that can benefit run faster, but >> > > also so that people looking at -Ofast documentation for options that >> > > could speed their programs find it. >> > > >> > > I have verified that with the following patch IPA-CP sees >> > > flag_semantic_interposition set to zero at Ofast and that info and pdf >> > > manual builds fine with the documentation change. I am bootstrapping >> > > and testing it now in order to comply with submission criteria but I >> > > don't think an Ofast change gets much tested. >> > > >> > > Assuming it passes, is the patch OK? (If it is, I will also add a note >> > > about it in the "Caveats" section in gcc-12/changes.html of wwwdocs >> > > after I commit the patch.) >> > > >> > >> > Unfortunately, I was wrong, there are testcases which use the optimize >> > attribute to switch a function to Ofast and those ICE because >> > -fsemantic-interposition is not an optimization flag and only >> > optimization flags can change in an optimize attribute (AFAIK, I only >> > had a quick glance at the results). >> > >> > I am not sure what is the right way to tackle this, whether to set the >> > flag at Ofast in some nonstandard way or make the flag an optimization >> > flag - probably affecting function definitions, having it affect >> > call-sites seems too fine-grained. I will try to discuss this on IRC on >> > Monday (and hope such change is still doable early stage3). >> > >> > Sorry for posting this a bit prematurely, >> >> Hi, >> >> This patch turns flag_semantic_interposition to optimization option so >> it can be enabled with per-function granuality. This is done by adding >> the flag among visibility flags into the symbol table. This fixes the >> behaviour on the testcase I added to testsuite. >> >> There are bugs where get_availability misbehaves on partitioned program. >> We can also use the new flag to fix those, but I will do that >> incrementally. >> >> The -Ofast change should be safe now. > > Also forgot to say it explicitly, the patch is OK, so please commit it. > Thanks a lot for the enabling patch. I have committed mine after re-testing. Martin
Re: [PATCH] options: Make -Ofast switch off -fsemantic-interposition
> > Hi, > > > > On Fri, Nov 12 2021, Martin Jambor wrote: > > > Hi, > > > > > > using -fno-semantic-interposition has been reported by various people > > > to bring about considerable speed up at the cost of strict compliance > > > to the ELF symbol interposition rules See for example > > > https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup > > > > > > As such I believe it should be implied by our -Ofast optimization > > > level, not only so that benchmarks that can benefit run faster, but > > > also so that people looking at -Ofast documentation for options that > > > could speed their programs find it. > > > > > > I have verified that with the following patch IPA-CP sees > > > flag_semantic_interposition set to zero at Ofast and that info and pdf > > > manual builds fine with the documentation change. I am bootstrapping > > > and testing it now in order to comply with submission criteria but I > > > don't think an Ofast change gets much tested. > > > > > > Assuming it passes, is the patch OK? (If it is, I will also add a note > > > about it in the "Caveats" section in gcc-12/changes.html of wwwdocs > > > after I commit the patch.) > > > > > > > Unfortunately, I was wrong, there are testcases which use the optimize > > attribute to switch a function to Ofast and those ICE because > > -fsemantic-interposition is not an optimization flag and only > > optimization flags can change in an optimize attribute (AFAIK, I only > > had a quick glance at the results). > > > > I am not sure what is the right way to tackle this, whether to set the > > flag at Ofast in some nonstandard way or make the flag an optimization > > flag - probably affecting function definitions, having it affect > > call-sites seems too fine-grained. I will try to discuss this on IRC on > > Monday (and hope such change is still doable early stage3). > > > > Sorry for posting this a bit prematurely, > > Hi, > > This patch turns flag_semantic_interposition to optimization option so > it can be enabled with per-function granuality. This is done by adding > the flag among visibility flags into the symbol table. This fixes the > behaviour on the testcase I added to testsuite. > > There are bugs where get_availability misbehaves on partitioned program. > We can also use the new flag to fix those, but I will do that > incrementally. > > The -Ofast change should be safe now. Also forgot to say it explicitly, the patch is OK, so please commit it. Honza
Re: [PATCH] options: Make -Ofast switch off -fsemantic-interposition
> Hi,
>
> On Fri, Nov 12 2021, Martin Jambor wrote:
> > Hi,
> >
> > using -fno-semantic-interposition has been reported by various people
> > to bring about considerable speed up at the cost of strict compliance
> > to the ELF symbol interposition rules See for example
> > https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup
> >
> > As such I believe it should be implied by our -Ofast optimization
> > level, not only so that benchmarks that can benefit run faster, but
> > also so that people looking at -Ofast documentation for options that
> > could speed their programs find it.
> >
> > I have verified that with the following patch IPA-CP sees
> > flag_semantic_interposition set to zero at Ofast and that info and pdf
> > manual builds fine with the documentation change. I am bootstrapping
> > and testing it now in order to comply with submission criteria but I
> > don't think an Ofast change gets much tested.
> >
> > Assuming it passes, is the patch OK? (If it is, I will also add a note
> > about it in the "Caveats" section in gcc-12/changes.html of wwwdocs
> > after I commit the patch.)
> >
>
> Unfortunately, I was wrong, there are testcases which use the optimize
> attribute to switch a function to Ofast and those ICE because
> -fsemantic-interposition is not an optimization flag and only
> optimization flags can change in an optimize attribute (AFAIK, I only
> had a quick glance at the results).
>
> I am not sure what is the right way to tackle this, whether to set the
> flag at Ofast in some nonstandard way or make the flag an optimization
> flag - probably affecting function definitions, having it affect
> call-sites seems too fine-grained. I will try to discuss this on IRC on
> Monday (and hope such change is still doable early stage3).
>
> Sorry for posting this a bit prematurely,
Hi,
This patch turns flag_semantic_interposition to optimization option so
it can be enabled with per-function granuality. This is done by adding
the flag among visibility flags into the symbol table. This fixes the
behaviour on the testcase I added to testsuite.
There are bugs where get_availability misbehaves on partitioned program.
We can also use the new flag to fix those, but I will do that
incrementally.
The -Ofast change should be safe now.
Bootstrapped/regtested x86_64-linux, comitted.
gcc/ChangeLog:
2021-11-18 Jan Hubicka
* cgraph.c (cgraph_node::get_availability): Update call of
decl_replaceable_p.
(cgraph_node::verify_node): Verify that semantic_interposition flag
is set correclty.
* cgraph.h: (symtab_node): Add semantic_interposition flag.
* cgraphclones.c (set_new_clone_decl_and_node_flags): Clear
semantic_interposition flag.
* cgraphunit.c (cgraph_node::finalize_function): Set
semantic_interposition flag.
(cgraph_node::add_new_function): Likewise.
(varpool_node::finalize_decl): Likewise.
(cgraph_node::create_wrapper): Likewise.
* common.opt (fsemantic-interposition): Turn to optimization node.
* lto-cgraph.c (lto_output_node): Stream semantic_interposition.
(lto_output_varpool_node): Likewise.
(input_overwrite_node): Likewise.
(input_varpool_node): Likewise.
* symtab.c (symtab_node::dump_base):
* varasm.c (decl_replaceable_p): Add semantic_interposition_p
parameter.
* varasm.h (decl_replaceable_p): Update declaration.
* varpool.c (varpool_node::ctor_useable_for_folding_p):
Use semantic_interposition flag.
(varpool_node::get_availability): Likewise.
(varpool_node::create_alias): Copy semantic_interposition flag.
gcc/cp/ChangeLog:
2021-11-18 Jan Hubicka
* decl.c (finish_function): Update use of decl_replaceable_p.
gcc/lto/ChangeLog:
2021-11-18 Jan Hubicka
* lto-partition.c (promote_symbol): Clear semantic_interposition flag.
gcc/testsuite/ChangeLog:
2021-11-18 Jan Hubicka
* gcc.dg/lto/semantic-interposition-1_0.c: New test.
* gcc.dg/lto/semantic-interposition-1_1.c: New test.
diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 466b66d5ba5..8e7c12642ad 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -2390,7 +2390,8 @@ cgraph_node::get_availability (symtab_node *ref)
to code cp_cannot_inline_tree_fn and probably shall be shared and
the inlinability hooks completely eliminated). */
- else if (decl_replaceable_p (decl) && !DECL_EXTERNAL (decl))
+ else if (decl_replaceable_p (decl, semantic_interposition)
+ && !DECL_EXTERNAL (decl))
avail = AVAIL_INTERPOSABLE;
else avail = AVAIL_AVAILABLE;
@@ -3486,6 +3487,13 @@ cgraph_node::verify_node (void)
"returns a pointer");
error_found = true;
}
+ if (definition && externally_visible
+ && semantic_interposition
+!= opt_for_fn (decl, flag_semantic_interposition))
+{
+ error ("semantic interposition
Re: [PATCH] options: Make -Ofast switch off -fsemantic-interposition
Hi,
On Fri, Nov 12 2021, Martin Jambor wrote:
> Hi,
>
> using -fno-semantic-interposition has been reported by various people
> to bring about considerable speed up at the cost of strict compliance
> to the ELF symbol interposition rules See for example
> https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup
>
> As such I believe it should be implied by our -Ofast optimization
> level, not only so that benchmarks that can benefit run faster, but
> also so that people looking at -Ofast documentation for options that
> could speed their programs find it.
>
> I have verified that with the following patch IPA-CP sees
> flag_semantic_interposition set to zero at Ofast and that info and pdf
> manual builds fine with the documentation change. I am bootstrapping
> and testing it now in order to comply with submission criteria but I
> don't think an Ofast change gets much tested.
>
> Assuming it passes, is the patch OK? (If it is, I will also add a note
> about it in the "Caveats" section in gcc-12/changes.html of wwwdocs
> after I commit the patch.)
>
Unfortunately, I was wrong, there are testcases which use the optimize
attribute to switch a function to Ofast and those ICE because
-fsemantic-interposition is not an optimization flag and only
optimization flags can change in an optimize attribute (AFAIK, I only
had a quick glance at the results).
I am not sure what is the right way to tackle this, whether to set the
flag at Ofast in some nonstandard way or make the flag an optimization
flag - probably affecting function definitions, having it affect
call-sites seems too fine-grained. I will try to discuss this on IRC on
Monday (and hope such change is still doable early stage3).
Sorry for posting this a bit prematurely,
Martin
>
>
> gcc/ChangeLog:
>
> 2021-11-12 Martin Jambor
>
> * opts.c (default_options_table): Switch off
> flag_semantic_interposition at Ofast.
> * doc/invoke.texi (Optimize Options): Document that Ofast switches off
> -fsemantic-interposition.
> ---
> gcc/doc/invoke.texi | 1 +
> gcc/opts.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 2ea23d07c4c..fd16c91aec8 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -10551,6 +10551,7 @@ valid for all standard-compliant programs.
> It turns on @option{-ffast-math}, @option{-fallow-store-data-races}
> and the Fortran-specific @option{-fstack-arrays}, unless
> @option{-fmax-stack-var-size} is specified, and @option{-fno-protect-parens}.
> +It turns off @option {-fsemantic-interposition}.
>
> @item -Og
> @opindex Og
> diff --git a/gcc/opts.c b/gcc/opts.c
> index caed6255500..3da53d8f890 100644
> --- a/gcc/opts.c
> +++ b/gcc/opts.c
> @@ -682,6 +682,7 @@ static const struct default_options
> default_options_table[] =
> /* -Ofast adds optimizations to -O3. */
> { OPT_LEVELS_FAST, OPT_ffast_math, NULL, 1 },
> { OPT_LEVELS_FAST, OPT_fallow_store_data_races, NULL, 1 },
> +{ OPT_LEVELS_FAST, OPT_fsemantic_interposition, NULL, 0 },
>
> { OPT_LEVELS_NONE, 0, NULL, 0 }
>};
> --
> 2.33.0
Re: [PATCH] options: Make -Ofast switch off -fsemantic-interposition
> Hi, > > using -fno-semantic-interposition has been reported by various people > to bring about considerable speed up at the cost of strict compliance > to the ELF symbol interposition rules See for example > https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup > > As such I believe it should be implied by our -Ofast optimization > level, not only so that benchmarks that can benefit run faster, but > also so that people looking at -Ofast documentation for options that > could speed their programs find it. > > I have verified that with the following patch IPA-CP sees > flag_semantic_interposition set to zero at Ofast and that info and pdf > manual builds fine with the documentation change. I am bootstrapping > and testing it now in order to comply with submission criteria but I > don't think an Ofast change gets much tested. > > Assuming it passes, is the patch OK? (If it is, I will also add a note > about it in the "Caveats" section in gcc-12/changes.html of wwwdocs > after I commit the patch.) > > Thanks, > > Martin > > > gcc/ChangeLog: > > 2021-11-12 Martin Jambor > > * opts.c (default_options_table): Switch off > flag_semantic_interposition at Ofast. > * doc/invoke.texi (Optimize Options): Document that Ofast switches off > -fsemantic-interposition. OK, thanks! Honza
[PATCH] options: Make -Ofast switch off -fsemantic-interposition
Hi,
using -fno-semantic-interposition has been reported by various people
to bring about considerable speed up at the cost of strict compliance
to the ELF symbol interposition rules See for example
https://fedoraproject.org/wiki/Changes/PythonNoSemanticInterpositionSpeedup
As such I believe it should be implied by our -Ofast optimization
level, not only so that benchmarks that can benefit run faster, but
also so that people looking at -Ofast documentation for options that
could speed their programs find it.
I have verified that with the following patch IPA-CP sees
flag_semantic_interposition set to zero at Ofast and that info and pdf
manual builds fine with the documentation change. I am bootstrapping
and testing it now in order to comply with submission criteria but I
don't think an Ofast change gets much tested.
Assuming it passes, is the patch OK? (If it is, I will also add a note
about it in the "Caveats" section in gcc-12/changes.html of wwwdocs
after I commit the patch.)
Thanks,
Martin
gcc/ChangeLog:
2021-11-12 Martin Jambor
* opts.c (default_options_table): Switch off
flag_semantic_interposition at Ofast.
* doc/invoke.texi (Optimize Options): Document that Ofast switches off
-fsemantic-interposition.
---
gcc/doc/invoke.texi | 1 +
gcc/opts.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 2ea23d07c4c..fd16c91aec8 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -10551,6 +10551,7 @@ valid for all standard-compliant programs.
It turns on @option{-ffast-math}, @option{-fallow-store-data-races}
and the Fortran-specific @option{-fstack-arrays}, unless
@option{-fmax-stack-var-size} is specified, and @option{-fno-protect-parens}.
+It turns off @option {-fsemantic-interposition}.
@item -Og
@opindex Og
diff --git a/gcc/opts.c b/gcc/opts.c
index caed6255500..3da53d8f890 100644
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -682,6 +682,7 @@ static const struct default_options default_options_table[]
=
/* -Ofast adds optimizations to -O3. */
{ OPT_LEVELS_FAST, OPT_ffast_math, NULL, 1 },
{ OPT_LEVELS_FAST, OPT_fallow_store_data_races, NULL, 1 },
+{ OPT_LEVELS_FAST, OPT_fsemantic_interposition, NULL, 0 },
{ OPT_LEVELS_NONE, 0, NULL, 0 }
};
--
2.33.0
