public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@kam.mff.cuni.cz>
To: Martin Jambor <mjambor@suse.cz>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
	Richard Biener <rguenther@suse.de>
Subject: Re: [PATCH] options: Make -Ofast switch off -fsemantic-interposition
Date: Fri, 19 Nov 2021 12:51:01 +0100	[thread overview]
Message-ID: <20211119115101.GA57358@kam.mff.cuni.cz> (raw)
In-Reply-To: <20211118173123.GC76860@kam.mff.cuni.cz>

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

  reply	other threads:[~2021-11-19 11:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-12 15:38 Martin Jambor
2021-11-12 15:40 ` Jan Hubicka
2021-11-12 22:14 ` Martin Jambor
2021-11-18 17:31   ` Jan Hubicka
2021-11-19 11:51     ` Jan Hubicka [this message]
2021-11-19 17:55       ` Martin Jambor
2022-05-11 21:25         ` Fāng-ruì Sòng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211119115101.GA57358@kam.mff.cuni.cz \
    --to=hubicka@kam.mff.cuni.cz \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=mjambor@suse.cz \
    --cc=rguenther@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).