[cfe-dev] [RFC] C++17 hardware constructive / destructive interference size

[James Y Knight via cfe-dev]

My own employer doesn't make ABI stability promises for that code, and thus
is fine with changing the value anytime it feels like. That's not a
generically viable strategy for a value provided by the standard library.

Additionally, before I sent that email, I looked at a number of the uses,
and it appeared as though a great many could be easily modified to use a
runtime-determined alignment.



On Fri, May 25, 2018 at 5:07 PM JF Bastien <jfbastien at apple.com> wrote:

>
>
> On May 25, 2018, at 2:01 PM, James Y Knight via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>
>
> On Fri, May 25, 2018 at 3:41 PM Richard Smith via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> On 25 May 2018 at 12:15, Hal Finkel via cfe-dev <cfe-dev at lists.llvm.org>
>> wrote:
>>
>>>
>>> On 05/25/2018 02:01 PM, Friedman, Eli via cfe-dev wrote:
>>>
>>> On 5/25/2018 11:46 AM, JF Bastien wrote:
>>>
>>>
>>>
>>> On May 25, 2018, at 11:38 AM, Friedman, Eli <efriedma at codeaurora.org>
>>> wrote:
>>>
>>> On 5/25/2018 11:29 AM, JF Bastien via cfe-dev wrote:
>>>
>>>
>>>    1. Teach the target infrastructure that hardware interference size
>>>    is something they can specify (in tablegen files somewhere).
>>>    2. Allow overriding the value in sub-targets using -march or -mcpu
>>>    (the sub-target defines the numeric value, and the user gets the overriden
>>>    one by using -march or -mcpu).
>>>
>>>
>>> We can't change the value based on -mcpu.  We generally allow mixing
>>> code built with different values of -mcpu.  And any code which is linked
>>> together must use the same value for
>>> hardware_destructive_interference_size, or else we violate ODR.
>>>
>>>
>>> Interesting point. The case I’d like to cover is one where the developer
>>> wants to get the exact right value for their particular CPU, instead of a
>>> conservative answer with extra padding. How do you think we should meet
>>> this use case?
>>>
>>>
>>> Go back to the standards committee and ask for a function that isn't
>>> constexpr?  I can't think of any other reasonable solution.
>>>
>>>
>>> Unfortunately, to define structure layouts they need to be constant.
>>>
>>> The best solution I've thought of is to extend the abi_tag support to
>>> force the mangling of interfaces depending on values of these constructs to
>>> be different.
>>>
>>
>> abi_tag is not an effective way of maintaining ABI, because it needs to
>> be "viral" / transitive, and can't be (at least, not without huge developer
>> effort).
>>
>> Perhaps we could add an attribute
>> to hardware_{con,de}structive_interference_size that produces a warning if
>> they are used outside the main source file? We'd also need to make them
>> non-inline, which is an observable conformance break, but seems unlikely to
>> be important compared to the other issues.
>>
>
> It'd certainly be unreasonable for a C++ stdlib to promise that the CPU's
> cache layout will never change. And, IMO, we'd be better off not
> implementing these functions, rather than trying to work around the issue
> with various warnings/restrictions.
>
> ISTM that user requirements may actually be best served by a non-constexpr
> function which can safely return the correct value on any platform. The
> situations where it's not feasible to use dynamically-allocated memory for
> such an object seem pretty slim. And if you're dynamically allocating
> memory, passing a runtime-constant alignment to the allocator is fine.
>
>
> I disagree, we need a constexpr value. The original paper has an example,
> from your own employer, which you’ll find copy / pasted all over the
> various forks of base/. Plenty of other projects just hard-code 64.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180525/55408657/attachment.html>