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

[JF Bastien via cfe-dev]

> 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 <mailto: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 <mailto: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 <mailto:efriedma at codeaurora.org>> wrote:
>>>> 
>>>> On 5/25/2018 11:29 AM, JF Bastien via cfe-dev wrote:
>>>>> Teach the target infrastructure that hardware interference size is something they can specify (in tablegen files somewhere).
>>>>> 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/bb62d88b/attachment.html>