Reduction support for the ApplyOp in buffer semantic form is implemented in #5731.
A discussion is needed around the dialect design to implement reductions for the value semantic form. More details about this can be found on this Zulip thread: #Beginners > Stencil Reductions (PR).
Buffer Semantic Form
In this form, modelling reductions as side effects works naturally. As it is already operating on memory (!stencil.field), mutation is expected, and writing into a pointer fits well with this.
stencil.apply(%24 = %data_field : !stencil.field<[0,8]x[0,8]xf64>) outs (%data_field_1 : !stencil.field<[0,8]x[0,8]xf64>) reductions (%reduction_data_ptr : !llvm.ptr) {
...
"stencil.reduce"(%29, %35) ({
^bb0(%36 : f64, %37 : f64):
%38 = arith.addf %36, %37 : f64
"stencil.reduce.return"(%38) : (f64) -> ()
}) : (f64, f64) -> ()
stencil.return %34 : f64
} to <[1, 1], [7, 7]>Value Semantic Form
However, in the value-semantic form, I believe the expectation is that operations behave like pure functions - all observable results must flow through SSA values. If a reduction produces a meaningful result but isn’t returned, it becomes a hidden side effect, which breaks SSA reasoning.
Because of this, reductions don’t translate cleanly as “side effects” in value semantics. Instead, they probably should be treated as explicit results of the computation, similar to how scf.reduce works.
A suggestion would be to split the models: in value semantics, reductions are returned as SSA values alongside the main stencil result, preserving purity; in buffer semantics, they remain side effects that write into memory.
Reduction support for the ApplyOp in buffer semantic form is implemented in #5731.
A discussion is needed around the dialect design to implement reductions for the value semantic form. More details about this can be found on this Zulip thread: #Beginners > Stencil Reductions (PR).
Buffer Semantic Form
In this form, modelling reductions as side effects works naturally. As it is already operating on memory (
!stencil.field), mutation is expected, and writing into a pointer fits well with this.Value Semantic Form
However, in the value-semantic form, I believe the expectation is that operations behave like pure functions - all observable results must flow through SSA values. If a reduction produces a meaningful result but isn’t returned, it becomes a hidden side effect, which breaks SSA reasoning.
Because of this, reductions don’t translate cleanly as “side effects” in value semantics. Instead, they probably should be treated as explicit results of the computation, similar to how
scf.reduceworks.A suggestion would be to split the models: in value semantics, reductions are returned as SSA values alongside the main stencil result, preserving purity; in buffer semantics, they remain side effects that write into memory.