[all-commits] [llvm/llvm-project] e94dc5: [RISCV] Inline scalar ceil/floor/trunc/rint/round/...

Craig Topper via All-commits all-commits at lists.llvm.org
Wed Oct 26 14:37:06 PDT 2022


  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: e94dc58dff1d693912904ba7ff743f67b3348d32
      https://github.com/llvm/llvm-project/commit/e94dc58dff1d693912904ba7ff743f67b3348d32
  Author: Craig Topper <craig.topper at sifive.com>
  Date:   2022-10-26 (Wed, 26 Oct 2022)

  Changed paths:
    M llvm/lib/Target/RISCV/RISCVISelLowering.cpp
    M llvm/lib/Target/RISCV/RISCVISelLowering.h
    M llvm/lib/Target/RISCV/RISCVInstrInfoD.td
    M llvm/lib/Target/RISCV/RISCVInstrInfoF.td
    M llvm/lib/Target/RISCV/RISCVInstrInfoZfh.td
    M llvm/lib/Target/RISCV/RISCVTargetTransformInfo.cpp
    M llvm/test/Analysis/CostModel/RISCV/fround.ll
    M llvm/test/CodeGen/RISCV/double-intrinsics.ll
    M llvm/test/CodeGen/RISCV/double-round-conv.ll
    M llvm/test/CodeGen/RISCV/float-intrinsics.ll
    M llvm/test/CodeGen/RISCV/float-round-conv-sat.ll
    M llvm/test/CodeGen/RISCV/float-round-conv.ll
    M llvm/test/CodeGen/RISCV/half-intrinsics.ll
    M llvm/test/CodeGen/RISCV/half-round-conv-sat.ll
    M llvm/test/CodeGen/RISCV/half-round-conv.ll

  Log Message:
  -----------
  [RISCV] Inline scalar ceil/floor/trunc/rint/round/roundeven.

This avoids the call overhead as well as the the save/restore of
fflags and the snan handling in the libm function.

The save/restore of fflags and snan handling are needed to be
correct for -ftrapping-math. I think we can ignore them in the
default environment.

The inline sequence will generate an invalid exception for nan
and an inexact exception if fractional bits are discarded.

I've used a custom inserter to explicitly create the control flow
around the float->int->float conversion.

We can probably avoid the final fsgnj after the conversion for
no signed zeros FMF, but I'll leave that for future work.

Note the comparison constant is slightly different than glibc uses.
They use 1<<53 for double, I'm using 1<<52. I believe either are valid.
Numbers >= 1<<52 can't have any fractional bits. It's ok to do the
float->int->float conversion on numbers between 1<<53 and 1<<52 since
they will all fit in 64. We only have a problem if the double can't fit
in i64

Reviewed By: reames

Differential Revision: https://reviews.llvm.org/D136508




More information about the All-commits mailing list