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

[Jason Merrill]

On 7/19/21 5:41 AM, Richard Earnshaw wrote:
> 
> 
> 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.
> 
> 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.

I don't see any reason to treat them differently.  The meaning of this 
option would be "set the interference sizes to be optimal for the 
current target CPU, without regard for ABI stability".  For x86 this 
wouldn't have any effect; for Arm/AArch64 it would set them to the 
tuning L1 cache line size, if set.

Here's what I have currently:

Jason
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-c-implement-C-17-hardware-interference-size.patch
Type: text/x-patch
Size: 21658 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20210720/8da11c99/attachment-0001.bin>