Page MenuHomePhabricator
Feed Advanced Search

Wed, Sep 23

jfb added inline comments to D87974: [Builtin] Add __builtin_zero_non_value_bits..
Wed, Sep 23, 10:10 AM · Restricted Project

Sat, Sep 19

jfb added inline comments to D87974: [Builtin] Add __builtin_zero_non_value_bits..
Sat, Sep 19, 4:14 PM · Restricted Project

Fri, Sep 18

jfb added a comment to D87858: [hip] Add HIP scope atomic ops..
In D87858#2280429, @jfb wrote:

Please provide documentation in this patch.

opencl atomic builtins are documented as notes to __c11_atomic builtins part of https://clang.llvm.org/docs/LanguageExtensions.html#builtin-functions. These new atomic builtins can be documented in a similar way after that.

Fri, Sep 18, 9:52 AM · Restricted Project

Thu, Sep 17

jfb added a comment to D87858: [hip] Add HIP scope atomic ops..

Please provide documentation in this patch.

Thu, Sep 17, 3:04 PM · Restricted Project

Tue, Sep 8

jfb updated subscribers of D87323: Bring atomic header closer to C++20.

Generally this looks good, but I didn't go into details.
It would be good to have an MS person like @STL_MSFT check that the std tests match, at least for what they've implemented.

Tue, Sep 8, 12:55 PM · Restricted Project
jfb added a comment to D78938: Make LLVM build in C++20 mode.

On C++20 mode rotting: it won't if someone sets up a bot. If it rots, then it's easier to un-rot with Barry's patch.

Tue, Sep 8, 10:26 AM · Restricted Project, Restricted Project

Mon, Sep 7

jfb added a comment to D79279: Add overloaded versions of builtin mem* functions.

ping

Mon, Sep 7, 11:04 AM · Restricted Project, Restricted Project

Thu, Sep 3

jfb committed rGbaa74e013f7e: Step down from security group (authored by jfb).
Step down from security group
Thu, Sep 3, 8:50 AM
jfb closed D86742: Step down from security group.
Thu, Sep 3, 8:50 AM · Restricted Project

Tue, Sep 1

jfb added a comment to D86917: [Asan] Cleanup atomic usage in allocator.
In D86917#2249793, @jfb wrote:

Is this really NFC?

I guess so, do you have particular concern?
I don't know particular cases where it was broken, but reading values some times as atomic and sometimes as not, plus unclear order of bit fields looks suspicions.

Tue, Sep 1, 2:06 PM · Restricted Project
jfb added a comment to D86917: [Asan] Cleanup atomic usage in allocator.

Is this really NFC?

Tue, Sep 1, 9:06 AM · Restricted Project

Aug 29 2020

jfb added a reviewer for D79279: Add overloaded versions of builtin mem* functions: rsmith.
Aug 29 2020, 3:52 PM · Restricted Project, Restricted Project
jfb requested changes to D33825: [clang-tidy] signal handler must be plain old function check.

MSC54-CPP refers to POF, which as I pointed out above isn't relevant anymore. I'd much rather have a diagnostic which honors the state of things after http://wg21.link/p0270.

Aug 29 2020, 3:47 PM · Restricted Project

Aug 28 2020

jfb requested changes to D33825: [clang-tidy] signal handler must be plain old function check.

Please consider these changes, and whether this is relevant as implemented: http://wg21.link/p0270

Aug 28 2020, 8:46 AM · Restricted Project

Aug 27 2020

jfb updated the summary of D86742: Step down from security group.
Aug 27 2020, 8:16 PM · Restricted Project
jfb committed rG82d29b397bb2: Add an unsigned shift base sanitizer (authored by jfb).
Add an unsigned shift base sanitizer
Aug 27 2020, 8:07 PM
jfb closed D86000: Add an unsigned shift base sanitizer.
Aug 27 2020, 8:06 PM · Restricted Project, Restricted Project, Restricted Project
jfb added a comment to D86742: Step down from security group.

I'll wait 5 days to do this, since our process says:

Aug 27 2020, 3:54 PM · Restricted Project
jfb updated subscribers of D86742: Step down from security group.
Aug 27 2020, 3:05 PM · Restricted Project
jfb requested review of D86742: Step down from security group.
Aug 27 2020, 3:02 PM · Restricted Project
jfb added inline comments to D86000: Add an unsigned shift base sanitizer.
Aug 27 2020, 1:32 PM · Restricted Project, Restricted Project, Restricted Project
jfb updated the diff for D86000: Add an unsigned shift base sanitizer.

Remove the "suppress this" in release notes.

Aug 27 2020, 1:32 PM · Restricted Project, Restricted Project, Restricted Project
jfb added inline comments to D86000: Add an unsigned shift base sanitizer.
Aug 27 2020, 10:38 AM · Restricted Project, Restricted Project, Restricted Project
jfb updated the diff for D86000: Add an unsigned shift base sanitizer.

Fix notes.

Aug 27 2020, 10:37 AM · Restricted Project, Restricted Project, Restricted Project
jfb added inline comments to D86000: Add an unsigned shift base sanitizer.
Aug 27 2020, 10:20 AM · Restricted Project, Restricted Project, Restricted Project
jfb updated the diff for D86000: Add an unsigned shift base sanitizer.

Address comments

Aug 27 2020, 10:19 AM · Restricted Project, Restricted Project, Restricted Project

Aug 26 2020

jfb updated the summary of D86000: Add an unsigned shift base sanitizer.
Aug 26 2020, 4:41 PM · Restricted Project, Restricted Project, Restricted Project
jfb updated the diff for D86000: Add an unsigned shift base sanitizer.

Re-upload with full context.

Aug 26 2020, 4:41 PM · Restricted Project, Restricted Project, Restricted Project
jfb updated the diff for D86000: Add an unsigned shift base sanitizer.

As Vedant suggested, make it part of 'integer' sanitizer.

Aug 26 2020, 4:39 PM · Restricted Project, Restricted Project, Restricted Project
jfb added a comment to D79279: Add overloaded versions of builtin mem* functions.

Thanks, I'm happy with this approach.

If I understand correctly, the primary (perhaps sole) purpose of __builtin_memcpy_sized is to provide a primitive from which an atomic operation can be produced. That being the case, I wonder if the name is emphasizing the wrong thing, and a name that contains atomic would be more obvious. As a concrete alternative, __atomic_unordered_memcpy is not much longer and seems to have the right kinds of implications. WDYT?

Aug 26 2020, 4:25 PM · Restricted Project, Restricted Project
jfb updated the diff for D79279: Add overloaded versions of builtin mem* functions.

Address Richard's comments.

Aug 26 2020, 4:22 PM · Restricted Project, Restricted Project
jfb abandoned D23041: Un-XFAIL GCC atomics.align.
Aug 26 2020, 8:41 AM
jfb abandoned D50593: ConstantMerge: merge common initial sequences.

This is probably still useful, if someone wants to pick it up.

Aug 26 2020, 8:41 AM · Restricted Project
jfb abandoned D65846: Improve error message from FrontendAction.
Aug 26 2020, 8:40 AM · Restricted Project
jfb abandoned D65493: Modernize atomic detection and usage.
Aug 26 2020, 8:39 AM · Restricted Project, Restricted Project, Restricted Project
jfb abandoned D66244: Compiler.h: remove old GCC checks, update docs.
Aug 26 2020, 8:39 AM · Restricted Project
jfb closed D65545: Handle some fs::remove failures.
Aug 26 2020, 8:38 AM · Restricted Project, Restricted Project
jfb abandoned D77219: UBSan ␇ runtime.

I don't think the world is ready for this.

Aug 26 2020, 8:38 AM · Restricted Project, Restricted Project

Aug 24 2020

jfb added a comment to D79279: Add overloaded versions of builtin mem* functions.

Ping, I think I've addressed all comments here.

Aug 24 2020, 10:59 AM · Restricted Project, Restricted Project

Aug 18 2020

jfb accepted D86043: [compiler-rt][builtins] Tweak checks for lock-free atomics.
In D86043#2222622, @jfb wrote:

Can you add a test that this works, e.g. by having a program which uses these functions, but doesn't link to libatomic?

This can be tested by my previous (under review) D81348. With this patch you can compile and link that test from D81348 when targeting RISC-V rv32imac, while without this patch that test will fail to link. (Tested with a complementary GNU baremetal newlib toolchain, which doesn't even have libatomic to link to.)

Aug 18 2020, 8:31 AM · Restricted Project

Aug 17 2020

jfb added a comment to D86043: [compiler-rt][builtins] Tweak checks for lock-free atomics.

Can you add a test that this works, e.g. by having a program which uses these functions, but doesn't link to libatomic?

Aug 17 2020, 2:41 PM · Restricted Project

Aug 14 2020

jfb added a comment to D86000: Add an unsigned shift base sanitizer.
In D86000#2219288, @vsk wrote:

It'd be nice to fold the new check into an existing sanitizer group to bring this to a wider audience. Do you foresee adoption issues for existing -fsanitize=integer adopters? Fwiw some recently-added implicit conversion checks were folded in without much/any pushback.

Aug 14 2020, 4:05 PM · Restricted Project, Restricted Project, Restricted Project
jfb updated subscribers of D86000: Add an unsigned shift base sanitizer.
Aug 14 2020, 2:53 PM · Restricted Project, Restricted Project, Restricted Project
jfb requested review of D86000: Add an unsigned shift base sanitizer.
Aug 14 2020, 2:51 PM · Restricted Project, Restricted Project, Restricted Project
jfb accepted D84049: Disable use of _ExtInt with '__atomic' builtins.

@ldionne should sign off on the libcxx test, but the rest seems fine to me. Eventually we probably want to enable something, but need to be consistent about it.

Aug 14 2020, 1:28 PM · Restricted Project, Restricted Project
jfb accepted D85975: [NFC] Fix typo and variable names.

The typo fix is fine, I'm not sure it's worth fixing variable names (since there's an ongoing discussion about renaming everything anyways).
FWIW C++ doesn't really have a lattice anymore: https://wg21.link/p0418

Aug 14 2020, 10:34 AM · Restricted Project

Aug 13 2020

jfb updated subscribers of D85900: [mlir] do not use llvm.cmpxchg with floats.

See for example r360421 D58251 D50491 D26266 D26266 r264845 D15471
Maybe talk to folks such as @reames ?

Aug 13 2020, 3:00 PM · Restricted Project
jfb added a comment to D79279: Add overloaded versions of builtin mem* functions.

Actually I think any subsequent updates to tests can be done in a follow-up patch, since I'm not changing the status-quo on address space here.

Aug 13 2020, 2:09 PM · Restricted Project, Restricted Project
jfb updated the diff for D79279: Add overloaded versions of builtin mem* functions.

Fix a test.

Aug 13 2020, 1:11 PM · Restricted Project, Restricted Project
jfb added a comment to D85900: [mlir] do not use llvm.cmpxchg with floats.

I'd expect us to go the other way, and allow this. There have been patches in the past to allow usage of atomics with float. Could you look with their authors and see what they advise here?

Aug 13 2020, 11:31 AM · Restricted Project
jfb updated the diff for D79279: Add overloaded versions of builtin mem* functions.

Update overloading as discussed: on the original builtins, and separate the _sized variant, making its 4th parameter non-optional. If this looks good, I'll need to update codege for a few builtins (to handle volatile), as well as add tests for their codegen and address space (which should already work, but isn't tested).

Aug 13 2020, 10:03 AM · Restricted Project, Restricted Project
jfb added a comment to D85044: Add __atomic_is_lock_free to compiler-rt.

Can you please add tests for this?

Aug 13 2020, 9:22 AM · Restricted Project, Restricted Project

Aug 12 2020

jfb added a comment to D85628: [HotColdSplitting] Add command line options for supplying cold function names via user input..
In D85628#2213940, @rjf wrote:
In D85628#2213919, @vsk wrote:

I’m not convinced this is a good idea. In what use case is it not possible to mark up relevant functions? It doesn’t make sense to me to make alternations to standard library functions within the compiler. It seems better to simply patch the standard library. In some cases llvm does infer function attributes for library functions, but these are generally lower level attributes that can’t be specified at the source level, and the attribute is made available to other passes in the pipeline.

Do you mean this patch isn't a good idea in general, or the recent revision isn't a good idea? For the latter, I'm not sure if you meant we should not outline declarations or we should not split the original loop into two (e.g. marking as cold before outlining). IMO splitting the loop into two simply addresses what the original intent of what we're doing, which is to mark certain functions as cold before outlining. Whereas, if we don't outline declarations via user-provided input, it renders @hiraditya 's proposed testcase useless. Alternatively, we don't have to make the testcase involving standard library functions if that's what you want :).

Aug 12 2020, 3:08 PM · Restricted Project
jfb added a comment to D85044: Add __atomic_is_lock_free to compiler-rt.

Does this x86 change actually match what the runtime does in the same file?

Aug 12 2020, 1:10 PM · Restricted Project, Restricted Project

Aug 11 2020

jfb added a comment to D79279: Add overloaded versions of builtin mem* functions.

I think it would be reasonable in general to guarantee that our __builtin_ functions have contracts at least as wide as the underlying C function, but allow them to have extensions, and to keep the plain C functions unextended. I had actually thought we already did that in more cases than we do (but perhaps I was thinking about the LLVM math intrinsics that guarantee to not set errno). That would mean that a C standard library implementation is still free to #define foo(x,y,z) __builtin_foo(x,y,z), but if they do, they may pick up extensions.

Aug 11 2020, 11:17 AM · Restricted Project, Restricted Project

Aug 10 2020

jfb added a comment to D85691: lld: link libatomic if needed for Timer.
In D85691#2208323, @jfb wrote:

You're probably better off putting the std::chrono::nanoseconds::rep behind a lock if it's not always lock free on all platforms. Some platforms just don't have libatomic, so this patch might cause other issues.

Wouldn't such a platform get a fatal error in llvm/cmake/modules/CheckAtomic.cmake?

Aug 10 2020, 3:59 PM · Restricted Project
jfb added a comment to D85691: lld: link libatomic if needed for Timer.

You're probably better off putting the std::chrono::nanoseconds::rep behind a lock if it's not always lock free on all platforms. Some platforms just don't have libatomic, so this patch might cause other issues.

Aug 10 2020, 3:31 PM · Restricted Project
jfb added a comment to D82892: [NFC] Methods to compare IR added in each IR subclass.

I didn't check that all of these compare all the required state for all opcodes.

Aug 10 2020, 3:00 PM · Restricted Project

Aug 5 2020

jfb added a comment to D79279: Add overloaded versions of builtin mem* functions.

Two observations that are new to me in this review:

  1. We already treat all builtins as being overloaded on address space.
  2. The revised patch treats __builtin_mem*_overloaded as being overloaded *only* on address space, volatility, and atomicity. (We've tuned the design to a point where the other qualifiers don't matter any more.)

So, we're adding three features here: overloading on (a) address space, (b) volatility, and (c) atomicity. (a) is already available in the non-_overloaded form, and we seem to be approaching agreement that (b) should be available in the non-_overloaded form too. So that only leaves (c), which is really not _overloaded but _atomic.

Based on those observations I'm now thinking that we might prefer a somewhat different approach (but one that should require only minimal changes to the patch in front of us). Specifically:

  1. Stop treating lib builtins (eg, plain memcpy) as overloaded on address space. That's a (pre-existing) conformance bug, at least for the Embedded C TR.
  2. Keep __builtin_ forms of lib builtins overloaded on address space. (No change.)
  3. Also overload __builtin_ forms of lib builtins on volatility where it makes sense, instead of adding new builtin names __builtin_mem*_overloaded.
  4. Add a new name for the builtin for the atomic forms of memcpy and memset (__builtin_memcpy_unordered_atomic maybe?).
  5. Convert the "trivial types" check from an error to a warning and apply it to all the mem* overloads. (Though I think we might actually already have such a check, so this might only require extending it to cover the atomic builtin.)

What do you think?

Aug 5 2020, 3:02 PM · Restricted Project, Restricted Project
jfb updated the diff for D79279: Add overloaded versions of builtin mem* functions.

Remove restrict, update docs, call isCompleteType

Aug 5 2020, 3:02 PM · Restricted Project, Restricted Project
jfb added inline comments to D79279: Add overloaded versions of builtin mem* functions.
Aug 5 2020, 2:42 PM · Restricted Project, Restricted Project
jfb updated the diff for D79279: Add overloaded versions of builtin mem* functions.

Use 'access size' instead of 'element size'.

Aug 5 2020, 2:42 PM · Restricted Project, Restricted Project
jfb added inline comments to D79279: Add overloaded versions of builtin mem* functions.
Aug 5 2020, 2:37 PM · Restricted Project, Restricted Project
jfb updated the diff for D79279: Add overloaded versions of builtin mem* functions.

Add loop test requested by Vedant

Aug 5 2020, 2:36 PM · Restricted Project, Restricted Project
jfb updated the diff for D79279: Add overloaded versions of builtin mem* functions.

Do UBSan change suggested by Vedant.

Aug 5 2020, 2:02 PM · Restricted Project, Restricted Project
jfb added inline comments to D84947: Add libFuzzer shared object build output.
Aug 5 2020, 11:27 AM · Restricted Project, Restricted Project

Aug 4 2020

jfb added a comment to D79279: Add overloaded versions of builtin mem* functions.

Patch looks basically okay to me, although I'll second Richard's concern that we shouldn't absent-mindedly start producing overloaded memcpys for ordinary __builtin_memcpy.

Aug 4 2020, 9:21 PM · Restricted Project, Restricted Project
jfb updated the diff for D79279: Add overloaded versions of builtin mem* functions.

Update docs

Aug 4 2020, 9:21 PM · Restricted Project, Restricted Project
jfb added inline comments to D79279: Add overloaded versions of builtin mem* functions.
Aug 4 2020, 5:57 PM · Restricted Project, Restricted Project
jfb added a comment to D79279: Add overloaded versions of builtin mem* functions.

Thanks for the detailed comments, I think I've addressed all of them! I also added UBSan support to check the builtin invocation. I think this patch is pretty much ready to go. A follow-up will need to add the support functions to compiler-rt (they're currently optional, as per https://reviews.llvm.org/D33240), and in cases where size is known we can inline them (as we do for memcpy and friends).

Aug 4 2020, 5:51 PM · Restricted Project, Restricted Project
jfb updated the diff for D79279: Add overloaded versions of builtin mem* functions.

Address Richard's comments, add UBSan support.

Aug 4 2020, 5:49 PM · Restricted Project, Restricted Project
jfb accepted D85239: [DOCS] Add more detail to stack protector documentation.
Aug 4 2020, 1:33 PM · Restricted Project
jfb committed rGe18c6ef6b41a: [clang] improve diagnostics for misaligned and large atomics (authored by tschuett).
[clang] improve diagnostics for misaligned and large atomics
Aug 4 2020, 11:11 AM
jfb closed D85102: [clang] improve diagnostics for misaligned and large atomics.
Aug 4 2020, 11:10 AM · Restricted Project

Aug 3 2020

jfb updated subscribers of D85044: Add __atomic_is_lock_free to compiler-rt.

This is technically a behavior change, someone like @ldionne ought to chime in, and we probably want to synchronize with libstdc++ @jwakely.

Aug 3 2020, 9:18 PM · Restricted Project, Restricted Project
jfb accepted D85102: [clang] improve diagnostics for misaligned and large atomics.
Aug 3 2020, 8:39 AM · Restricted Project

Jul 31 2020

jfb added a comment to D79279: Add overloaded versions of builtin mem* functions.

This is almost ready I think!
There are a few things still open, I'd love feedback on them.

Jul 31 2020, 11:30 AM · Restricted Project, Restricted Project
jfb updated the diff for D79279: Add overloaded versions of builtin mem* functions.

Address Richard's comments.

Jul 31 2020, 11:30 AM · Restricted Project, Restricted Project
jfb added a comment to D85009: [Sema][BFloat] Forbid arithmetic on vectors of bfloat..
In D85009#2187621, @jfb wrote:
In D85009#2187549, @jfb wrote:

Is that true of all vector bfloat implementations? It seems like arithmetic on these types is something implementations would likely support.

As I understand it, Arm currently has the only implementation in clang so far. But if other targets disagree, we can make this conditional on getVectorKind(), so that VectorType::NeonVector gets this restriction and other vector types get whatever they need.

You mean: only aarch64 backend supports lowering bfloat16 vectors at the moment? Because the clang support isn't "ARM bfloat", it's just bfloat. The tests are ARM bfloat and I think that's fine (i.e. Sema should be able to check ISA-specific problems), but in general this property your checking for seems like a target property.

If I write C or C++ code using bfloat, I'd like to know what that type actually means and what I can do with it. As a developer, it'll be super frustrating once other targets support bfloat... should those target have their own bfloat (because it won't be compatible with ARM's), or should bfloat work differently on different targets?

I actually don't know what the intended approach is here, which is why I'm asking :)

Yes there is an Intel bfloat type too, however we are the only target for the bfloat c/ir type so far. The jury is also out as far as the standards are concerned too, the best we can do now is prevent behavior we know is not compatible, and like Simon says, add some predication later

Jul 31 2020, 9:25 AM · Restricted Project
jfb added a comment to D85009: [Sema][BFloat] Forbid arithmetic on vectors of bfloat..
In D85009#2187549, @jfb wrote:

Is that true of all vector bfloat implementations? It seems like arithmetic on these types is something implementations would likely support.

As I understand it, Arm currently has the only implementation in clang so far. But if other targets disagree, we can make this conditional on getVectorKind(), so that VectorType::NeonVector gets this restriction and other vector types get whatever they need.

Jul 31 2020, 9:14 AM · Restricted Project
jfb added a comment to D85009: [Sema][BFloat] Forbid arithmetic on vectors of bfloat..

Is that true of all vector bfloat implementations? It seems like arithmetic on these types is something implementations would likely support.

Jul 31 2020, 9:02 AM · Restricted Project

Jul 29 2020

jfb updated subscribers of D84049: Disable use of _ExtInt with '__atomic' builtins.
In D84049#2182011, @jfb wrote:

Hi, @jfb.

_Atomic appears to already have special logic for _ExtInt in clang::Sema::BuildAtomicType. If _Atomic is used with an _ExtInt whose size is not a power of 2, or whose size is less then 8 bits, then it's disallowed. Those cases already have tests in clang/test/SemaCXX/ext-int.cpp.

Interesting. It seems like __atomic ought to be consistent with this, and we'd make it official ABI?

std::atomic appears to use and call the __atomic builtins, so it emits this patch's new diagnostic that disallows _ExtInt. Unfortunately I can't add the std::atomic<_ExtInt(N)> to a sema lit test because I can't #include the real atomic, but I did verify it locally.

Can you add the test to libc++? @ldionne WDYT?

IF we are going as far as modifying libc++, perhaps we can just add a SFINAE test to std::atomic to disallow the _ExtInt types? That said, it won't help with libstdc++.

Either way, I suspect that is better placed in a different patch, and should no longer hold up this patch.

Jul 29 2020, 9:28 AM · Restricted Project, Restricted Project
jfb updated subscribers of D84049: Disable use of _ExtInt with '__atomic' builtins.

Hi, @jfb.

_Atomic appears to already have special logic for _ExtInt in clang::Sema::BuildAtomicType. If _Atomic is used with an _ExtInt whose size is not a power of 2, or whose size is less then 8 bits, then it's disallowed. Those cases already have tests in clang/test/SemaCXX/ext-int.cpp.

Jul 29 2020, 8:23 AM · Restricted Project, Restricted Project

Jul 28 2020

jfb committed rG389f009c5757: [NFC] Sema: use checkArgCount instead of custom checking (authored by jfb).
[NFC] Sema: use checkArgCount instead of custom checking
Jul 28 2020, 1:42 PM
jfb closed D84666: [NFC] Sema: use checkArgCount instead of custom checking.
Jul 28 2020, 1:41 PM · Restricted Project

Jul 27 2020

jfb added inline comments to D79279: Add overloaded versions of builtin mem* functions.
Jul 27 2020, 5:29 PM · Restricted Project, Restricted Project
jfb updated subscribers of D79279: Add overloaded versions of builtin mem* functions.

I've addressed @rsmith @rjmccall suggestions (unless noted), thanks!
An open question: as of 6e4aa1e48138182685431c76184dfc36e620aea2 @dneilson added an assertion on CreateElementUnorderedAtomicMemCpy to check that the pointer arguments have alignments of at least the element size. That makes sense when the IR is only ever built internally to LLVM, but now that I'm adding a builtin it's more of a dynamic property. Should I also force this in the frontend (understanding that alignment isn't always well known at compile time), or should simply assume that the alignment is correct because it's a dynamic property?

Jul 27 2020, 5:24 PM · Restricted Project, Restricted Project
jfb updated the diff for D79279: Add overloaded versions of builtin mem* functions.

Address comments

Jul 27 2020, 5:24 PM · Restricted Project, Restricted Project
Herald added a project to D84666: [NFC] Sema: use checkArgCount instead of custom checking: Restricted Project.
Jul 27 2020, 8:34 AM · Restricted Project

Jul 23 2020

jfb added a comment to D79279: Add overloaded versions of builtin mem* functions.

Do you think it'd be useful to have different guarantees for different operands? I guess it could come up, but it'd be a whole lot of extra complexity that I can't imagine we'd ever support.

You mean, if element_size is passed then you get different guarantees?

No, sorry, I mean different guarantees for the different pointer operands. In principle, we could allow you to say that the memcpy has to be done with 4-byte accesses from the source and 2-byte accesses to the destination. That's implementable but a lot of work.

Jul 23 2020, 11:30 AM · Restricted Project, Restricted Project
jfb added a comment to D79279: Add overloaded versions of builtin mem* functions.

I think the argument is treated as if it were 1 if not given. That's all that ordinary memcpy formally guarantees, which seems to work fine (semantically, if not performance-wise) for pretty much everything today.

Jul 23 2020, 10:52 AM · Restricted Project, Restricted Project
jfb added a comment to D79279: Add overloaded versions of builtin mem* functions.

I don't think any of these should allow _Atomic unless we're going to give it some sort of consistent atomic semantics (which is hard to imagine being useful), and I think you should just take an extra argument of the minimum access width on all of them uniformly if you think that's important. Builtins can have optional arguments.

Jul 23 2020, 10:29 AM · Restricted Project, Restricted Project
jfb added a comment to D79279: Add overloaded versions of builtin mem* functions.

My point is that this has nothing to do with the ordinary semantics of _Atomic. You're basically just looking at the word "atomic" and saying that, hey, a minimum access size is sortof related to atomicity.

If you want this to be able to control the minimum access size, you should allow that to be passed in as an optional argument instead.

Jul 23 2020, 10:17 AM · Restricted Project, Restricted Project
jfb updated the diff for D79279: Add overloaded versions of builtin mem* functions.

Re-update

Jul 23 2020, 8:21 AM · Restricted Project, Restricted Project
jfb updated the diff for D79279: Add overloaded versions of builtin mem* functions.

Improve documentation

Jul 23 2020, 8:20 AM · Restricted Project, Restricted Project
jfb added a comment to D79279: Add overloaded versions of builtin mem* functions.
In D79279#2168533, @jfb wrote:

Is there a need for an atomic memcpy at all? Why is it useful to allow this operation to take on "atomic" semantics — which aren't actually atomic because the loads and stores to elements are torn — with hardcoded memory ordering and somewhat arbitrary rules about what the atomic size is?

Hans lays out a rationale for usefulness in his paper, but what I've implemented is more useful: it's *unordered* so you can fence as you desire around it, yet it guarantees a minimum memory access size based on the pointer parameters. For example, copying an atomic int will be 4 byte operations which are single-copy-atomic, but the accesses from one int to the next aren't performed in any guaranteed order (or observable in any guaranteed order either). I talked about this with him a while ago but IIRC he wasn't sure about implementation among other things, so when you asked me to widen my original volatile-only memcpy to also do other qualifiers, I realized that it was a neat way to do atomic as well as other qualifiers. I've talked to a few SG1 folks about this, and I believe (for other reasons too) it's where the design will end up for Hans' paper.

I can see the usefulness of this operation, but it seems like a odd semantic mismatch for what is basically just a memcpy where one of the pointers happens to have _Atomic type, like you're shoe-horning it into this builtin just to avoid declaring a different one.

Jul 23 2020, 8:09 AM · Restricted Project, Restricted Project

Jul 22 2020

jfb added a comment to D79279: Add overloaded versions of builtin mem* functions.

Is there a need for an atomic memcpy at all? Why is it useful to allow this operation to take on "atomic" semantics — which aren't actually atomic because the loads and stores to elements are torn — with hardcoded memory ordering and somewhat arbitrary rules about what the atomic size is?

Jul 22 2020, 8:32 PM · Restricted Project, Restricted Project
jfb added inline comments to D79279: Add overloaded versions of builtin mem* functions.
Jul 22 2020, 5:39 PM · Restricted Project, Restricted Project
jfb updated the diff for D79279: Add overloaded versions of builtin mem* functions.

Address all but one of John's comments

Jul 22 2020, 5:39 PM · Restricted Project, Restricted Project
jfb updated the diff for D79279: Add overloaded versions of builtin mem* functions.

Follow John's suggestions

Jul 22 2020, 11:26 AM · Restricted Project, Restricted Project