[PATCH] D12633: Implement ACLE 2.0 macros of chapters 6.6 and 6.7 for [ARM] and [Aarch64] targets

[Alexandros Lamprineas via cfe-commits]

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.


http://reviews.llvm.org/D12633

Files:
  include/clang/Basic/LangOptions.def
  lib/Basic/Targets.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/Preprocessor/aarch64-target-features.c
  test/Preprocessor/arm-target-features.c

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D12633.35628.patch
Type: text/x-patch
Size: 5289 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20150924/4f0f2f4b/attachment.bin>