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

Hal Finkel via cfe-dev cfe-dev at lists.llvm.org
Fri May 25 12:15:10 PDT 2018


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.

 -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
> 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/1aff0630/attachment.html>


More information about the cfe-dev mailing list