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

[Richard Smith via cfe-dev]

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

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


>  -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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180525/513ad6a3/attachment.html>