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

[James Y Knight via cfe-dev]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180525/43f6baf1/attachment.html>