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

Tue Oct 23 20:17:53 PDT 2018

> On Oct 23, 2018, at 5:34 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> 
> On Tue, 23 Oct 2018 at 13:09, JF Bastien via cfe-dev <cfe-dev at lists.llvm.org <mailto: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 <mailto: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?
> 
> Sure; given the constraints and the intent of WG21 it seems like it's the best we can do.
> 
> It seems novel to me to use a builtin function rather than a predefined macro, but I'm not fundamentally opposed. Have you thought about whether the value should be exposed to preprocessor conditionals? (That seems like the big difference between using a macro and using a builtin for this.) Related: have you talked to WG14 about such a feature? (I'd guess -- but I don't know -- that they'd want to expose the value as a macro, and allow its use in preprocessor constant expressions.)

I have not, I can add it to the list of things I need to write WG14 papers for. My experience with WG14’s mailing list hasn’t been great when pointing out simple things WG21 did related to atomics, so I don’t think a mere email will do.

>> On Thu, May 31, 2018 at 12:43 PM David Blaikie via cfe-dev <cfe-dev at lists.llvm.org <mailto: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 <mailto:cfe-dev at lists.llvm.org>> wrote:
>> 
>> 
>> On Tue, May 29, 2018 at 4:39 PM JF Bastien <jfbastien at apple.com <mailto:jfbastien at apple.com>> wrote:
>> 
>>> On May 25, 2018, at 3:12 PM, James Y Knight <jyknight at google.com <mailto:jyknight at google.com>> wrote:
>>> 
>>> 
>>> 
>>> On Fri, May 25, 2018 at 5:30 PM JF Bastien <jfbastien at apple.com <mailto:jfbastien at apple.com>> wrote:
>>> 
>>> 
>>>> On May 25, 2018, at 2:23 PM, James Y Knight <jyknight at google.com <mailto: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 <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>
>> _______________________________________________
>> 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>
>> 
>> 
>> -- 
>> -Brian
>> _______________________________________________
>> 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>
> 
> _______________________________________________
> 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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181023/aaf3219e/attachment.html>