[PATCH] c++: implement C++17 hardware interference size

[Richard Earnshaw]

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.