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

[Hal Finkel via cfe-dev]

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:
>>>>>>>
>>>>>>>      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).
>>
>> 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?

 -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/89b541eb/attachment.html>