[all-commits] [llvm/llvm-project] 727328: [X86] Add back fmaddsub intrinsics to work towards...
topperc via All-commits
all-commits at lists.llvm.org
Mon Feb 24 12:07:36 PST 2020
Branch: refs/heads/master
Home: https://github.com/llvm/llvm-project
Commit: 727328433ad61b8c7acdd4d63e73241303a6beb7
https://github.com/llvm/llvm-project/commit/727328433ad61b8c7acdd4d63e73241303a6beb7
Author: Craig Topper <craig.topper at intel.com>
Date: 2020-02-24 (Mon, 24 Feb 2020)
Changed paths:
M clang/lib/CodeGen/CGBuiltin.cpp
M clang/test/CodeGen/avx512f-builtins.c
M clang/test/CodeGen/avx512vl-builtins.c
M clang/test/CodeGen/fma-builtins-constrained.c
M clang/test/CodeGen/fma-builtins.c
M clang/test/CodeGen/fma4-builtins.c
M llvm/include/llvm/IR/IntrinsicsX86.td
M llvm/lib/IR/AutoUpgrade.cpp
M llvm/lib/Target/X86/X86IntrinsicsInfo.h
Log Message:
-----------
[X86] Add back fmaddsub intrinsics to work towards fixing the strict fp implementation
Previously we emitted an fmadd and a fmadd+fneg and combined them with a shufflevector. But this doesn't follow the correct exception behavior for unselected elements so the backend can't merge them into the fmaddsub/fmsubadd instructions.
This patch restores the the fmaddsub intrinsics so we don't have two arithmetic operations. We lose out on optimization opportunity in the non-strict FP case, but I don't think this is a big loss. If someone gives us a test case we can look into adding instcombine/dagcombine improvements. I'd rather not have the frontend do completely different things for strict and non-strict.
This still has problems because target specific intrinsics don't support strict semantics yet. We also still have all of the problems with masking. But we at least generate the right instruction in constrained mode now.
Differential Revision: https://reviews.llvm.org/D74268
More information about the All-commits
mailing list