[all-commits] [llvm/llvm-project] a59f71: [flang][hlfir] do not consider local temps as conf...

jeanPerier via All-commits all-commits at lists.llvm.org
Wed Oct 23 03:34:35 PDT 2024


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: a59f7124349fc42e6aa8031796f310bb883d95de
      https://github.com/llvm/llvm-project/commit/a59f7124349fc42e6aa8031796f310bb883d95de
  Author: jeanPerier <jperier at nvidia.com>
  Date:   2024-10-23 (Wed, 23 Oct 2024)

  Changed paths:
    M flang/lib/Optimizer/HLFIR/Transforms/ScheduleOrderedAssignments.cpp
    A flang/test/HLFIR/order_assignments/vector-subscripts-scheduling.fir
    M flang/test/HLFIR/order_assignments/where-scheduling.f90

  Log Message:
  -----------
  [flang][hlfir] do not consider local temps as conflicting in assignment (#113330)

Last patch required to avoid creating a temporary for the LHS when
dealing with `x([a,b]) = y`.

The code dealing with "ordered assignments" (where, forall, user and
vector subscripted assignments) is saving the evaluated RHS/LHS and
masks if they have write effects because this write effects should not
be evaluated when they affect entities that may be written to in other
contexts after the evaluation and before the re-evaluation.

But when dealing with write to storage allocated in the region for the
expression being evluated, there is no problem to re-evaluate the write:
it has no effect outside of the expression evaluation that owns the
allocation.

In the case of `x([a,b]) = y`, the temporary is created for the vector
subscript. Raising the HLFIR abstraction for simple array constructors
may be a good idea, but local temps are created in other contexts, so
this fix is more generic.



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


More information about the All-commits mailing list