[all-commits] [llvm/llvm-project] e42f86: [flang][nfc] Support volatility in Fir ops (#134858)

[Asher Mancinelli via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: e42f8609858f3e6ba004032a4750f0bcd5d466be
      https://github.com/llvm/llvm-project/commit/e42f8609858f3e6ba004032a4750f0bcd5d466be
  Author: Asher Mancinelli <ashermancinelli at gmail.com>
  Date:   2025-04-09 (Wed, 09 Apr 2025)

  Changed paths:
    M flang/include/flang/Optimizer/Builder/FIRBuilder.h
    M flang/include/flang/Optimizer/Dialect/FIROps.h
    M flang/include/flang/Optimizer/Dialect/FIROps.td
    M flang/include/flang/Optimizer/Dialect/FIROpsSupport.h
    M flang/lib/Lower/ConvertExprToHLFIR.cpp
    M flang/lib/Optimizer/Builder/FIRBuilder.cpp
    M flang/lib/Optimizer/Dialect/FIROps.cpp
    M flang/test/Fir/cse.fir
    M flang/test/Fir/invalid.fir

  Log Message:
  -----------
  [flang][nfc] Support volatility in Fir ops (#134858)

Part two of merging #132486. Support volatility in fir ops.

* Introduce a new operation fir.volatile_cast, whose only purpose is to
add or take away the volatility of an SSA value's type. The types must
be otherwise identical, and any other type conversions must be handled
by fir.convert. fir.convert will give an error if the volatility of the
inputs does not match, such that all changes to volatility must be
handled explicitly through fir.volatile_cast.
* Add memory effects to ops that read from or write to memory. The
precedent for this comes from the LLVM dialect (feb7beaf70) where
llvm.load/store ops with the volatile attribute report read/write
effects to a generic memory resource. This change is similar in spirit
but different in two ways: the volatility of an operation is determined
by the type of its memref, not an attribute on the op, and the memory
effects of a load- or store-like operation on a volatile reference type
are reported against a particular memory resource,
`VolatileMemoryResource`. This is so MLIR optimizations are able to
reorder operations that are not volatile around operations that are,
which we believe more precisely models LLVM's volatile memory semantics.
@vzakhari suggested this in #132486 citing LangRef. See
https://llvm.org/docs/LangRef.html#volatile-memory-accesses

Changes needed to generate IR with volatile types are not included in
this change, so it should be non-functional, containing only the changes
to Fir ops and op utilities that will be needed once we enable lowering
to generate volatile types.



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications