================
@@ -134,7 +134,7 @@ end function f
!CHECK-NEXT: run 1 save : where/mask
!CHECK-NEXT: run 2 evaluate: where/region_assign1
!CHECK-LABEL: ------------ scheduling where in _QPonly_once ------------
-!CHECK-NEXT: unknown effect: %{{[0-9]+}} = llvm.intr.stacksave : !llvm.ptr
+!CHECK-NEXT: unknown effect: %11 = fir.call @_QPcall_me_only_once()
fastmath<contract> : () -> !fir.array<10x!fir.logical<4>>
----------------
jeanPerier wrote:
Because the llvm.intr.stacksave is not emitted anymore (at that point and in
general).
At the point of the pipeline where the FORALL/WHERE logic is
optimized/implemented, the call is now wrapped inside an hlfir.eval_in_mem, so
it has not yet been decided if and how to allocate the storage, so there is no
point emitting those ops in lowering anymore.
In general because hlfir.eval_in_mem now uses heap allocation for dynamically
sized results like all other temps created in bufferization (it is more
consistent and easier).
The analysis stops at the first unknow side effects, so the unknown side effect
of the function call is not new, but it is now the first one encountered (which
is an improvement if anything).
https://github.com/llvm/llvm-project/pull/118070
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
