[all-commits] [llvm/llvm-project] eb4690: [flang][Lower] Add alternative real expression low...

[Tom Eccles via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: eb4690c251141b7d4ef31f321acc6fb3dc09a1bf
      https://github.com/llvm/llvm-project/commit/eb4690c251141b7d4ef31f321acc6fb3dc09a1bf
  Author: Tom Eccles <tom.eccles at arm.com>
  Date:   2026-07-08 (Wed, 08 Jul 2026)

  Changed paths:
    M flang/include/flang/Evaluate/tools.h
    M flang/lib/Evaluate/tools.cpp
    M flang/lib/Lower/Bridge.cpp
    M flang/lib/Lower/ConvertExprToHLFIR.cpp
    A flang/test/Lower/split-sum-expression-tree-lowering.f90

  Log Message:
  -----------
  [flang][Lower] Add alternative real expression lowering (#207371)

This is opt-in by an engineering option and disabled by default.

In section 10.1.5.2.4 of the 2023 Fortran standard "Evaluation of
numerical intrinsic operations", the standard explicitly allows
alternate mathematically equivalent lowerings. For example the source
expression X + Y + Z could be evaluated (X + Y) + Z, X + (Y + Z) or even
(X + Z) + Y, etc.

The open source benchmark SNBone shows significantly better results with
classic flang because classic flang emits real arithmetic expressions in
a different order. In the case of this benchmark it reduces dependency
depth for instructions issued to the vector unit, allowing for more of
the arithmetic to be parallelised over multiple vector execution units
in the ALU.

The lowering added by this patch tries to mimic the way classic flang
orders instructions for these expressions. I did not read any classic
flang source when writing this patch. There is still a notable
difference in that classic flang uses FMA intrinsics whereas LLVM Flang
relies on the rest of the pipeline to introduce FMA when it is safe to
do so.

This is a much less aggressive optimisation than simply enabling reassoc
in the fast-math flags because it does not allow reassociation between
Fortran language statements. This is why I implemented it in lowering.

The new option enables an experimental lowering path for scalar real
top-level addition chains. When enabled with
-enable-split-sum-expression-tree-lowering, eligible sums are split
after the first two terms and rebuilt as a right-associated tail plus
head. This lets the independent tail terms be evaluated before the
assignment-related head, giving the backend a different expression tree
while leaving the default lowering unchanged.

The transform is deliberately narrow. It only applies to scalar real RHS
expressions in assignments and rejects cases with vector subscripts,
parentheses, subtraction, procedure references, or volatile/asynchronous
symbols on either side of the assignment. Subtraction is left out
because the split would need to carry signed terms; division stays
within an individual additive term and does not change the top-level
chain.

In testing I have found some tests in the Fujitsu test suite miscompare
due to small changes in floating point rounding. There are no failures
or regressions in SPEC2017 or SPEC2026. I think it would be legal
according to the Fortran standard to enable this by default, but I am
not proposing that here, and will not consider it until after the LLVM
release branch point.

Assisted-by: Codex



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