From: Richard Earnshaw <Richard.Earnshaw@foss.arm.com>
To: Jason Merrill <jason@redhat.com>, Matthias Kretz <m.kretz@gsi.de>
Cc: "Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com>,
Jonathan Wakely <jwakely.gcc@gmail.com>,
GNU C Library <libc-alpha@sourceware.org>,
libstdc++ <libstdc++@gcc.gnu.org>,
gcc-patches List <gcc-patches@gcc.gnu.org>,
Jonathan Wakely <jwakely@redhat.com>
Subject: Re: [PATCH] c++: implement C++17 hardware interference size
Date: Mon, 19 Jul 2021 10:41:18 +0100 [thread overview]
Message-ID: <c44382c4-902b-927d-e7a3-9eb80259b749@foss.arm.com> (raw)
In-Reply-To: <CADzB+2=z6gSwpp+vscWpUweyc0XK8JfF1OimC2+eGtZgbyOiWg@mail.gmail.com>
On 17/07/2021 22:37, Jason Merrill via Gcc-patches wrote:
> On Sat, Jul 17, 2021 at 6:55 AM Matthias Kretz <m.kretz@gsi.de> wrote:
>
>> On Saturday, 17 July 2021 15:32:42 CEST Jonathan Wakely wrote:
>>> On Sat, 17 Jul 2021, 09:15 Matthias Kretz, <m.kretz@gsi.de> wrote:
>>>> If somebody writes a library with `keep_apart` in the public API/ABI
>> then
>>>> you're right.
>>>
>>> Yes, it's fine if those constants don't affect anything across module
>>> boundaries.
>>
>> I believe a significant fraction of hardware interference size usage will
>> be
>> internal.
>>
>
> I would hope for this to be the vast majority of usage. I want the warning
> to discourage people from using the interference size variables in the
> public API of a library.
>
>
>>>> The developer who wants his code to be included in a distro should care
>>>> about
>>>> binary distribution. If his code has an ABI issue, that's a bug he
>> needs
>>>> to
>>>> fix. It's not the fault of the packager.
>>>
>>> Yes but in practice it's the packagers who have to deal with the bug
>>> reports, analyze the problem, and often fix the bug too. It might not be
>>> the packager's fault but it's often their problem
>>
>> I can imagine. But I don't think requiring users to specify the value
>> according to what -mtune suggests will improve things. Users will write a
>> configure/cmake/... macro to parse the value -mtune prints and pass that
>> on
>> the command line (we'll soon find this solution on SO 😜). I.e. things are
>> likely to be even more broken.
>
>
> Simpler would be a flag to say "set them based on -mtune", e.g.
> -finterference-tuning or --param destructive-intereference-size=tuning.
> That would be just as easy to write as -Wno-interference-size.
>
> Jason
>
Please be very careful about an option name like that. The x86 meaning
and interpretation of -mtune is subtly different to that of Arm and
AArch64 and possibly other targets as well.
Also, should the behaviour of a compiler configured with --with-cpu=foo
be handled differently to a command-line option that sets foo
explicitly? In the back-end I'm not sure we can really tell the difference.
R.
next prev parent reply other threads:[~2021-07-19 9:41 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20210716023656.670004-1-jason@redhat.com>
2021-07-16 2:41 ` Jason Merrill
2021-07-16 2:48 ` Noah Goldstein
2021-07-16 11:17 ` Jonathan Wakely
2021-07-16 13:27 ` Richard Earnshaw
2021-07-16 13:26 ` Jonathan Wakely
2021-07-16 15:12 ` Matthias Kretz
2021-07-16 15:30 ` Jason Merrill
2021-07-16 16:54 ` Jonathan Wakely
2021-07-16 18:43 ` Jason Merrill
2021-07-16 19:26 ` Matthias Kretz
2021-07-16 19:58 ` Jonathan Wakely
2021-07-17 8:14 ` Matthias Kretz
2021-07-17 13:32 ` Jonathan Wakely
2021-07-17 13:54 ` Matthias Kretz
2021-07-17 21:37 ` Jason Merrill
2021-07-19 9:41 ` Richard Earnshaw [this message]
2021-07-20 16:43 ` Jason Merrill
2021-07-20 18:05 ` Thomas Rodgers
2021-07-16 17:20 ` Noah Goldstein
2021-07-16 19:37 ` Matthias Kretz
2021-07-16 21:23 ` Noah Goldstein
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=c44382c4-902b-927d-e7a3-9eb80259b749@foss.arm.com \
--to=richard.earnshaw@foss.arm.com \
--cc=Richard.Earnshaw@arm.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jason@redhat.com \
--cc=jwakely.gcc@gmail.com \
--cc=jwakely@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=libstdc++@gcc.gnu.org \
--cc=m.kretz@gsi.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).