[PATCH] D12633: Implement ACLE 2.0 macros of chapters 6.6 and 6.7 for [ARM] and [Aarch64] targets
Alexandros Lamprineas via cfe-commits
cfe-commits at lists.llvm.org
Thu Sep 24 07:53:22 PDT 2015
labrinea updated this revision to Diff 35628.
labrinea added a comment.
@t.p.northover I think we should not be defining _ARM_FP_FENV_ROUNDING on neither of ARM and AArch64 targets since "-frounding-math" is not available on clang: clang/llvm don't support C99 FP rounding mode pragmas (FENV_ACCESS etc) <https://llvm.org/bugs/show_bug.cgi?id=8100>
@rengolin Clang translates frontend GCC compliant flags to cc1 flags:
- -fno-honor-infinities => -menable-no-infs
- -fno-honor-nans => -menable-no-nans
- AND( -fassociative-math, -freciprocal-math, -fno-signed-zeros, -fno-trapping-math, -fno-math-errno ) => -menable-unsafe-fp-math
Those flags seem to affect an LLVM IR in two ways:
- function attributes (no-infs-fp-math = yes|no, no-nans-fp-math = yes|no, unsafe-fp-math = yes|no)
- fast-math flags used with generated fp-math operators (this doc summarizes the LLVM-IR fast-math flags <http://llvm.org/docs/LangRef.html#fastmath>)
I think we should not be checking **Opts.FiniteMathOnly** since it only indicates whether optimizations assume the arguments and result to be +/-inf. We should not be checking **Opts.FastMath** either since it might be the case where //-menable-unsafe-fp-math// is set but //-ffast-math// is not set. Then the user would rely on _ARM_FP_FAST being absent but in reality the backend would emit unsafe fp math IR. My patch introduces a new lang option to handle this case.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5289 bytes
Desc: not available
More information about the cfe-commits