The reduction analysis/codegen in RV makes no distinction between ordered (strict) and un-ordered reductions, neither during reduction detection, not during codegen.
This should be improved to enable:
1.) in-order reductions (that is do not privatize the accumulation variable(s), reduce in every loop iteration using a strict reduction
2.) fast-math reduction (privatize the accumulator, reduce using an unordered, fast-math reduction).
RV currently employs an inconsistent mix of these two where reductions are privatized in SIMD code but the generated reduction code does not use the fast-math flags.
The reduction analysis/codegen in RV makes no distinction between ordered (strict) and un-ordered reductions, neither during reduction detection, not during codegen.
This should be improved to enable:
1.) in-order reductions (that is do not privatize the accumulation variable(s), reduce in every loop iteration using a strict reduction
2.) fast-math reduction (privatize the accumulator, reduce using an unordered, fast-math reduction).
RV currently employs an inconsistent mix of these two where reductions are privatized in SIMD code but the generated reduction code does not use the fast-math flags.