[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