[flang-commits] [flang] [flang][rfc] Add represention of volatile references (PR #132486)

[Asher Mancinelli via flang-commits]

================
@@ -0,0 +1,21 @@
+// RUN: fir-opt --convert-hlfir-to-fir %s -o - | FileCheck %s
+func.func @foo() {
+  %true = arith.constant true
+  %false = arith.constant false
+  %0 = fir.alloca !fir.logical<4> {bindc_name = "a", uniq_name = "_QFEa"}
+  %1 = fir.convert %0 : (!fir.ref<!fir.logical<4>>) -> !fir.ref<!fir.logical<4>, volatile>
+  %2:2 = hlfir.declare %1 {fortran_attrs = #fir.var_attrs<volatile>, uniq_name = "_QFEa"} : (!fir.ref<!fir.logical<4>, volatile>) -> (!fir.ref<!fir.logical<4>, volatile>, !fir.ref<!fir.logical<4>, volatile>)
----------------
ashermancinelli wrote:

1. I use `fir.convert` to convert `hlfir.declare`'s input ref into a volatile ref if it has the volatile attribute set. I'm not opposed to a separate volatile_cast op: it would ensure any casts between volatile and non volatile types are explicit/intentional, and the `fir.convert` verifier could check that it's _not_ converting between types with different volatility but are otherwise identical, so nobody accidentally drops volatility on the floor. Is this why you suggest it, or are there other reasons too? 
2. It _would_ work the other way (modeling volatility on ops instead of the type). This is how the LLVM dialect models volatility and is an option we considered, but there are some issues:
    * Because some hlfir ops access multiple chunks of memory, we'd need some way to indicate which operand should be considered volatile. The only way I see to do that is to represent volatility as an attribute on the ops indicating which operands are volatile, and attrs are easily lost and not easily propagated.
    * When we model volatility on the type, we get the propagation for free. Let's say we have `hlfir.declare_volatile` mirroring `hlfir.declare` and both return regular ref types. Should every use of the declared op check if the operand's defining op is a volatile declare or a regular one to check if the use should be volatile as well? All users get this information for free if it's represented on their input types.

https://github.com/llvm/llvm-project/pull/132486