hubert-reinterpretcast wrote:
> To my mind, the most defensible behavior for `__builtin_fma` (and future
> similar builtins) is this: they have the same behavior with respect to
> constant expression evaluation, rounding mode, and strict FP mode (i.e.,
> `FENV_ACCESS`) as a humble `+` operator. That is, in the cases where they are
> manifestly constant-evaluated, they take on the rounding mode implied by
> `FENV_ROUND`.
This sounds reasonable (if it is still your position after considering the
macro-replacement situation).
To summarize (assuming we use the same behaviour for both the prefixed and
non-prefixed cases):
- manifestly constant-evaluated:
- obey `FENV_ROUND`; `FE_DYNAMIC` is treated the same as default (i.e., to
nearest)
- note: `FENV_ROUND` affects the invocations lexically within its scope
(i.e., it does not transfer from caller to callee, and it has the same
challenges with default function arguments and default member initializers as
`FENV_ACCESS`)
- not manifestly constant-evaluated:
- `FENV_ACCESS` is "on": do not evaluate in the compiler
- `FENV_ACCESS` is "off": disregard `FENV_ROUND`; use the default rounding
mode (expect cases that should obey `FENV_ROUND` to be macro replaced)
https://github.com/llvm/llvm-project/pull/158048
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
