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

[JF Bastien via cfe-dev]

> On May 25, 2018, at 2:09 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> 
> 
> On 05/25/2018 03:41 PM, JF Bastien wrote:
>> 
>> 
>>> On May 25, 2018, at 1:34 PM, Hal Finkel <hfinkel at anl.gov <mailto:hfinkel at anl.gov>> wrote:
>>> 
>>> 
>>> On 05/25/2018 02:40 PM, Richard Smith 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).
>>> 
>>> Interesting. I had thought that abi_tag was transitive.
>>> 
>>> It occurs to me that Transitive ABI Infection Mechanism (TAIM) has a reasonable acronym. :-) - I suspect that's what we need in this case.
>>> 
>>>> 
>>>> 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?
>>> 
>>> I thought about suggesting this, but didn't, because I suspect that many/most uses will be in header files, just project-internal header files (because they'll be defining structure layouts, padding arrays, etc.). I think that such a warning will be pretty noisy, unfortunately.
>>> 
>>>> 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.
>>> 
>>> Good point. Do you think that we should file a DR about this? I imagine that most everyone is going to be in the same boat in this regard.
>> 
>> MSVC only ever sets it to 64, so they don’t have this issue.
> 
> For both values on all platforms?

Yes: https://twitter.com/MalwareMinigun/status/1000114366883155968 <https://twitter.com/MalwareMinigun/status/1000114366883155968>


>  -Hal
> 
>> 
>> 
>>>  -Hal
>>> 
>>>>  
>>>>  -Hal 
>>>> 
>>>>> 
>>>>> -Eli
>>>>> -- 
>>>>> Employee of Qualcomm Innovation Center, Inc.
>>>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
>>>>> 
>>>>> 
>>>>>  _______________________________________________
>>>>> cfe-dev mailing list
>>>>> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>>>> 
>>>> -- 
>>>> Hal Finkel
>>>> Lead, Compiler Technology and Programming Languages
>>>> Leadership Computing Facility
>>>> Argonne National Laboratory
>>>> 
>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>>>> 
>>>> 
>>> 
>>> -- 
>>> Hal Finkel
>>> Lead, Compiler Technology and Programming Languages
>>> Leadership Computing Facility
>>> Argonne National Laboratory
>> 
> 
> -- 
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180525/a93a6e51/attachment.html>