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

Tue Oct 23 17:56:29 PDT 2018

On Tue, Oct 23, 2018 at 1:09 PM JF Bastien via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

>
> On Oct 20, 2018, at 2:08 PM, Brian Cain via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
> Resurrecting this thread after the lightning talk on the matter.  IIRC the
> TL;DR might be something like "the proposal is no worse than the status
> quo, despite its drawbacks."
>
> Was there further discussion at llvm-dev?  Any closer to consensus?
>
>
> I haven’t heard other feedback from the dev meeting. Seems folks are happy
> with the 9 point plan?
>

Curious how you're planning on dealing with things like subtarget support,
inlining, and code generation. :)

-eric

>
>
> On Thu, May 31, 2018 at 12:43 PM David Blaikie via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> [+echristo because he's been thinking about some of these things
>> (especially those highlighted in (1)) since implementing the target
>> attribute support & looking at how to build code optimized for specific
>> subtargets]
>>
>> On Wed, May 30, 2018 at 12:39 PM James Y Knight via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>>>
>>>
>>> On Tue, May 29, 2018 at 4:39 PM JF Bastien <jfbastien at apple.com> wrote:
>>>
>>>>
>>>> On May 25, 2018, at 3:12 PM, James Y Knight <jyknight at google.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>> On Fri, May 25, 2018 at 5:30 PM JF Bastien <jfbastien at apple.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On May 25, 2018, at 2:23 PM, James Y Knight <jyknight at google.com>
>>>>> wrote:
>>>>>
>>>>> My own employer doesn't make ABI stability promises for that code, and
>>>>> thus is fine with changing the value anytime it feels like. That's not a
>>>>> generically viable strategy for a value provided by the standard library.
>>>>>
>>>>> Additionally, before I sent that email, I looked at a number of the
>>>>> uses, and it appeared as though a great many could be easily modified to
>>>>> use a runtime-determined alignment.
>>>>>
>>>>>
>>>>> That would be useful feedback on the paper… prior to it getting into
>>>>> C++17. The committee’s POV voting the paper in was that having a constexpr
>>>>> value was something we wanted, and so that’s what we have. At this point in
>>>>> time I’d like to focus on implementing C++17 as it is, and / or filing DRs
>>>>> as required.
>>>>>
>>>>
>>>> Sure. I'm not on the committee. Even if I was, I certainly don't know
>>>> that I would have identified the problem...
>>>>
>>>> But now that it has been identified, there's a choice of what to
>>>> do. And not implementing the function (and presumably filing a DR saying
>>>> so) is seeming like a pretty reasonable option.
>>>>
>>>>
>>>> The committee discussed ABI issues (Jacksonville 2016) and decided that
>>>> they’d rather have them than have a proliferation of #define SOMETHING 64.
>>>> That discussion occurred with Google folks in the room, it might be higher
>>>> bandwidth to consult with them? The notes are unfortunately quite sparse
>>>> for that discussion.
>>>>
>>>> The libc++ community shouldn't decline to implement a feature without
>>>> bringing concrete feedback to the committee. Without such feedback, I’d
>>>> like to move forward with an implementation plan, because we should offer
>>>> full C++17 support regardless of our distaste for specific features. I’ve
>>>> received good feedback on the thread so far, I’m happy to leave the
>>>> discussion open for a bit, talk to committee people next week in
>>>> Rapperswil, and unless feedback goes the committee’s way I’d like to pursue
>>>> an implementation. Does this sound fair?
>>>>
>>>
>>> There's been 3 options discussed so far -- I'm not sure which (#1 or #2)
>>> you're now proposing to implement.
>>>
>>> 1. Return an subtarget-dependent value, depending on the exact CPU model
>>> selected at compile-time.
>>>   Good: Allows for better memory-usage/performance.
>>>   Bad: Potential risk of ODR violations/ABI issues, due to dependency on
>>> cpu tuning flags.
>>>   Bad: Potential risk of same across versions of the compiler, if the
>>> default generic cpu tuning is changed.
>>>
>>> 2. Choose a single "good enough" constant value for each platform.
>>>   Good: eliminate ABI/ODR issues.
>>>   Bad: value might be too conservative for users' desires.
>>>     e.g. returning 128 for hardware_destructive_interference_size when
>>> 64 would've been sufficient will waste memory.
>>>   Bad: Future CPU changes might invalidate the constant generic value,
>>> requiring either that it be changed (introducing an ABI issue again), or
>>> remain incorrect forever.
>>>     e.g. most ARM chips have had 64-byte cache-lines for a while now,
>>> so that would've seemed the only reasonable number to choose on ARM up
>>> until recently. But, now, some of the newest CPUs have apparently switched
>>> to 128-byte cache-lines; should we change to 128?
>>>
>>> (Or, 2b: YOLO, 64 bytes should be good enough for all platforms!)
>>>
>>> 3. Decline to implement at all.
>>>   Good: avoid these issues.
>>>   Bad: users who need it must do something themselves, e.g. choose some
>>> arbitrary value e.g. 64.
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> cfe-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
>
> --
> -Brian
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
> _______________________________________________
> 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/20181023/bc5d1eaa/attachment.html>