mibintc added inline comments.
================ Comment at: clang/docs/UsersManual.rst:1318 + mode informs the compiler that it must not assume any particular + rounding mode. + ---------------- rjmccall wrote: > rjmccall wrote: > > "represent *the* corresponding IEEE rounding rules" > A few points about this documentation that occurred to me since the last time > I looked at it: > > - It's weird to talk about LLVM here, since this is the Clang documentation. > Clang's behavior is not specified in terms of the IR it generates; it's > specified in terms of the formal behavior of the source code. Therefore this > documentation should talk about things using concepts from an appropriate > language standard whenever possible; in this case, C99 works. > > - It's weird to bring up all these different rounding modes when this option > doesn't actually let you do anything with them. If you want to talk about > rounding modes in general that's fine as a way of informing the programmer, > but we shouldn't give them information they can't use. > > - I don't think `-fno-rounding-math` is actually equivalent to forcing the > use of the `tonearest` rounding mode; I think it *assumes* that the rounding > mode is set to `tonearest`. (Or am I wrong and this is actually guaranteed > by ABI?) > > - I don't think we want to *define* `-frounding-math` as exactly equivalent > to `-ffp-model=strict`. That might be a convenient implementation for now, > but it seems to me that `-frounding-math` still allows some optimizations > that `-ffp-model=strict` wouldn't. > > With that in mind, I'd suggest something like this: > > > Force floating-point operations to honor the dynamically-set rounding mode > > by default. > > > > The result of a floating-point operation often cannot be exactly > > represented in the result type and therefore must be rounded. IEEE 754 > > describes different rounding modes that control how to perform this > > rounding, not all of which are supported by all implementations. C > > provides interfaces (``fesetround`` and ``fesetenv``) for dynamically > > controlling the rounding mode, and while it also recommends certain > > conventions for changing the rounding mode, these conventions are not > > typically enforced in the ABI. Since the rounding mode changes the > > numerical result of operations, the compiler must understand something > > about it in order to optimize floating point operations. > > > > Note that floating-point operations performed as part of constant > > initialization are formally performed prior to the start of the program and > > are therefore not subject to the current rounding mode. This includes the > > initialization of global variables and local ``static`` variables. > > Floating-point operations in these contexts will be rounded using > > ``FE_TONEAREST``. > > > > - The option ``-fno-rounding-math`` allows the compiler to assume that the > > rounding mode is set to ``FE_TONEAREST``. This is the default. > > - The option ``-frounding-math`` forces the compiler to honor the > > dynamically-set rounding mode. This prevents optimizations which might > > affect results if the rounding mode changes or is different from the > > default; for example, it prevents floating-point operations from being > > reordered across most calls and prevents constant-folding when the result > > is not exactly representable. Thank you, I will work on another patch Repository: rL LLVM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62731/new/ https://reviews.llvm.org/D62731 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
