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

[Richard Smith via cfe-dev]

On 25 May 2018 at 13:34, Hal Finkel via cfe-dev <cfe-dev at lists.llvm.org>
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>
> 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>
>> 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.
>

That's not possible, because classes can be forward-declared, and you need
to know what fields and base classes they have to transitively propagate
the taint.

GCC tries make it possible to transitively propagate the taint manually:
they have a warning for a type that uses a tainted type and isn't itself
declared with the abi_tag attribute. But in practice (at least for the
"C++11 ABI" abi_tag) the taint ends up affecting sufficiently many classes
as to make using the attribute that way infeasible to all but the most
dedicated.

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

Yes, we probably should. Making them non-inline would presumably mean that
we can tell the user it's their fault if the value differs between
translation units and they use it in an ODR-relevant context. That doesn't
solve the problem, but it does make it not our problem to solve, to a
certain extent. We're still left with this being a dangerous feature, but I
think that's really unavoidable if we want these things to be compile-time
constants.


>  -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 listcfe-dev at lists.llvm.orghttp://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
>> 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
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180525/e2047904/attachment.html>