- Jun 12, 2020
-
-
Stanislav Mekhanoshin authored
-
- Apr 02, 2020
-
-
Matt Arsenault authored
-
- Mar 06, 2020
-
-
Matt Arsenault authored
This reverts commit 737394c4. The fp-model test was failing on platforms that enable denormal flushing based on -ffast-math. This needs to reset to IEEE, not the default in these cases. Change-Id: Ibbad32f66d0d0b89b9c1173a3a96fb1a570ddd89
-
- Mar 05, 2020
-
-
Jeremy Morse authored
This reverts commit c64ca930. This patch tripped a few build bots: http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/24703/ http://lab.llvm.org:8011/builders/clang-cmake-x86_64-avx2-linux/builds/13465/ http://lab.llvm.org:8011/builders/clang-with-lto-ubuntu/builds/15994/ Reverting to clear the bots.
-
Matt Arsenault authored
The IR hasn't switched the default yet, so explicitly add the ieee attributes. I'm still not really sure how the target default denormal mode should interact with -fno-unsafe-math-optimizations. The target may have selected the default mode to be non-IEEE based on the flags or based on its true behavior, but we don't know which is the case. Since the only users of a non-IEEE mode without a flag still support IEEE mode, just reset to IEEE.
-
- Jan 28, 2020
-
-
Konstantin Pyzhov authored
Corrected clang amdgpu-features.cl test for 6d614a82 (AMDGPU MFMA built-ins) Differential Revision: https://reviews.llvm.org/D72723
-
- Jan 18, 2020
-
-
Matt Arsenault authored
Currently there are 4 different mechanisms for controlling denormal flushing behavior, and about as many equivalent frontend controls. - AMDGPU uses the fp32-denormals and fp64-f16-denormals subtarget features - NVPTX uses the nvptx-f32ftz attribute - ARM directly uses the denormal-fp-math attribute - Other targets indirectly use denormal-fp-math in one DAGCombine - cl-denorms-are-zero has a corresponding denorms-are-zero attribute AMDGPU wants a distinct control for f32 flushing from f16/f64, and as far as I can tell the same is true for NVPTX (based on the attribute name). Work on consolidating these into the denormal-fp-math attribute, and a new type specific denormal-fp-math-f32 variant. Only ARM seems to support the two different flush modes, so this is overkill for the other use cases. Ideally we would error on the unsupported positive-zero mode on other targets from somewhere. Move the logic for selecting the flush mode into the compiler driver, instead of handling it in cc1. denormal-fp-math/denormal-fp-math-f32 are now both cc1 flags, but denormal-fp-math-f32 is not yet exposed as a user flag. -cl-denorms-are-zero, -fcuda-flush-denormals-to-zero and -fno-cuda-flush-denormals-to-zero will be mapped to -fp-denormal-math-f32=ieee or preserve-sign rather than the old attributes. Stop emitting the denorms-are-zero attribute for the OpenCL flag. It has no in-tree users. The meaning would also be target dependent, such as the AMDGPU choice to treat this as only meaning allow flushing of f32 and not f16 or f64. The naming is also potentially confusing, since DAZ in other contexts refers to instructions implicitly treating input denormals as zero, not necessarily flushing output denormals to zero. This also does not attempt to change the behavior for the current attribute. The LangRef now states that the default is ieee behavior, but this is inaccurate for the current implementation. The clang handling is slightly hacky to avoid touching the existing denormal-fp-math uses. Fixing this will be left for a future patch. AMDGPU is still using the subtarget feature to control the denormal mode, but the new attribute are now emitted. A future change will switch this and remove the subtarget features.
-
- Sep 05, 2019
-
-
Matt Arsenault authored
llvm-svn: 371010
-
- Jul 09, 2019
-
-
Stanislav Mekhanoshin authored
Differential Revision: https://reviews.llvm.org/D64430 llvm-svn: 365528
-
- Jun 22, 2019
-
-
Matt Arsenault authored
This wasn't setting some of the features from older generations. llvm-svn: 364123
-
- Jun 14, 2019
-
-
Stanislav Mekhanoshin authored
Differential Revision: https://reviews.llvm.org/D63308 llvm-svn: 363345
-
- May 14, 2019
-
-
Stanislav Mekhanoshin authored
Differential Revision: https://reviews.llvm.org/D61875 llvm-svn: 360634
-
- Apr 05, 2019
-
-
Stanislav Mekhanoshin authored
Differential Revision: https://reviews.llvm.org/D60293 llvm-svn: 357792
-
- Feb 09, 2019
-
-
Stanislav Mekhanoshin authored
Differential Revision: https://reviews.llvm.org/D57972 llvm-svn: 353588
-
- Jan 10, 2019
-
-
Stanislav Mekhanoshin authored
Differential Revision: https://reviews.llvm.org/D56525 llvm-svn: 350794
-
- Aug 08, 2018
-
-
Matt Arsenault authored
Fast FMAF is not a sufficient condition to enable denormals. Before VI, enabling denormals caused F32 instructions to run at F64 speeds. llvm-svn: 339278
-
- Aug 07, 2018
-
-
Matt Arsenault authored
llvm-svn: 339110
-
Matt Arsenault authored
llvm-svn: 339109
-
- Apr 30, 2018
-
-
Matt Arsenault authored
Changes by Matt Arsenault Konstantin Zhuravlyov llvm-svn: 331216
-