[PATCH] D87974: [Builtin] Add __builtin_zero_non_value_bits.

__simt__ added a comment. I think Jonathan is asking whether there is a match in the gray areas. The two cases people bring up most: 1. Unions, where the padding overlaps for all the possible active members. 2. Tail padding, up to the allocator granularity / alignment size. If the

[PATCH] D87974: [Builtin] Add __builtin_zero_non_value_bits.

__simt__ added a comment. I've resumed looking at the library code. How should I check for support? Is it going to be e.g. `__has_feature(__builtin_clear_padding)`? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D87974/new/

[PATCH] D74918: Add method to TargetInfo to get CPU cache line size

__simt__ added a comment. In D74918#1897636 , @kristof.beyls wrote: > If these values are part of the C++ target platform ABI, it seems to me the > values for std::hardware_{constructive,destructive}_interference_size should > be set by whoever has the

[PATCH] D74918: Add method to TargetInfo to get CPU cache line size

__simt__ added a comment. (//I assume I'm not seeing a code review being used to veto a C++ Standard feature, but actually the other points are the reason for the red flag.//) I can see a desire for hyper-precise definitions to achieve the best possible performance, but we really need a

[PATCH] D71726: Let clang atomic builtins fetch add/sub support floating point types

__simt__ added a comment. In D71726#1792852 , @yaxunl wrote: > In D71726#1791904 , @jfb wrote: > > > This generally seems fine. Does it work on most backends? I want to make > > sure it doesn't fail in backends :)