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

[Hal Finkel via cfe-dev]

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.

 -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/069a35aa/attachment.html>