[Openmp-commits] [PATCH] D62393: [OPENMP][NVPTX]Mark parallel level counter as volatile.

[Hal Finkel via Phabricator via Openmp-commits]

hfinkel added a comment.

In D62393#1539014 <https://reviews.llvm.org/D62393#1539014>, @ABataev wrote:

> In D62393#1539012 <https://reviews.llvm.org/D62393#1539012>, @jfb wrote:
>
> > FWIW we already support `-fms-volatile`, so there's precedent if you wanted `-fnv-volatile` (however terrible that is).
>
>
> Most probably, we don't need this option, clang should emit correct code for volatile vars in Cuda mode automatically.


+1

That having been said, maybe this is a very simple change because it is the same as (or very similar to) what MSVolatile does?

  /// An LValue is a candidate for having its loads and stores be made atomic if
  /// we are operating under /volatile:ms *and* the LValue itself is volatile and
  /// performing such an operation can be performed without a libcall.
  bool CodeGenFunction::LValueIsSuitableForInlineAtomic(LValue LV) {
    if (!CGM.getCodeGenOpts().MSVolatile) return false;
    AtomicInfo AI(*this, LV);
    bool IsVolatile = LV.isVolatile() || hasVolatileMember(LV.getType());
    // An atomic is inline if we don't need to use a libcall.
    bool AtomicIsInline = !AI.shouldUseLibcall();
    // MSVC doesn't seem to do this for types wider than a pointer.
    if (getContext().getTypeSize(LV.getType()) >
        getContext().getTypeSize(getContext().getIntPtrType()))
      return false;
    return IsVolatile && AtomicIsInline;
  }

Making this return true for when LangOpts.CUDAIsDevice might essentially do what we need?


Repository:
  rOMP OpenMP

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D62393/new/

https://reviews.llvm.org/D62393