================ @@ -0,0 +1,19 @@ +//===--- AtomicOptions.def - Atomic Options database -------------*- C++ -*-===// +// +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception +// +//===----------------------------------------------------------------------===// +// This file defines the Atomic language options. Users of this file +// must define the OPTION macro to make use of this information. +#ifndef OPTION +# error Define the OPTION macro to handle atomic language options +#endif + +// OPTION(name, type, width, previousName) +OPTION(NoRemoteMemory, bool, 1, First) +OPTION(NoFineGrainedMemory, bool, 1, NoRemoteMemory) +OPTION(IgnoreDenormalMode, bool, 1, NoFineGrainedMemory) ---------------- yxsamliu wrote:
I understand the desire to avoid negative naming in APIs. However, in this case, the negative naming (NoRemoteMemory, NoFineGrainedMemory) actually better reflects the IR structure. By default, atomic instructions in IR have no metadata, which corresponds to the conservative worst case (memory may be remote/fine-grained). The metadata we add serves as explicit performance hints promising the memory is not remote/fine-grained. If we used positive names like RemoteMemory, it would imply there's a default remote_memory metadata in IR, which isn't true and could cause confusion. The current negative naming makes it clearer that we're adding explicit metadata to opt out of the conservative default behavior. https://github.com/llvm/llvm-project/pull/114841 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
