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

JF Bastien via cfe-dev cfe-dev at lists.llvm.org
Tue May 29 13:39:16 PDT 2018


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


More information about the cfe-dev mailing list