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

[JF Bastien via cfe-dev]

> On May 25, 2018, at 1:34 PM, Hal Finkel <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.


>  -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

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