[all-commits] [llvm/llvm-project] 9c54ee: [SimplifyLibCalls] Take size of int into considera...

[Björn Pettersson via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 9c54ee437898314f956cfc048d9038ca775ea692
      https://github.com/llvm/llvm-project/commit/9c54ee437898314f956cfc048d9038ca775ea692
  Author: Bjorn Pettersson <bjorn.a.pettersson at ericsson.com>
  Date:   2021-06-02 (Wed, 02 Jun 2021)

  Changed paths:
    M llvm/include/llvm/Analysis/TargetLibraryInfo.h
    M llvm/lib/Analysis/TargetLibraryInfo.cpp
    M llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp
    M llvm/test/Transforms/InstCombine/exp2-1.ll
    M llvm/test/Transforms/InstCombine/pow_fp_int.ll
    M llvm/test/Transforms/InstCombine/simplify-libcalls.ll

  Log Message:
  -----------
  [SimplifyLibCalls] Take size of int into consideration when emitting ldexp/ldexpf

When rewriting
  powf(2.0, itofp(x)) -> ldexpf(1.0, x)
  exp2(sitofp(x)) -> ldexp(1.0, sext(x))
  exp2(uitofp(x)) -> ldexp(1.0, zext(x))

the wrong type was used for the second argument in the ldexp/ldexpf
libc call, for target architectures with 16 bit "int" type.
The transform incorrectly used a bitcasted function pointer with
a 32-bit argument when emitting the ldexp/ldexpf call for such
targets.

The fault is solved by using the correct function prototype
in the call, by asking TargetLibraryInfo about the size of "int".
TargetLibraryInfo by default derives the size of the int type by
assuming that it is 16 bits for 16-bit architectures, and
32 bits otherwise. If this isn't true for a target it should be
possible to override that default in the TargetLibraryInfo
initializer.

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


  Commit: d1273d39d377dffeab684ca58176302dbad6c629
      https://github.com/llvm/llvm-project/commit/d1273d39d377dffeab684ca58176302dbad6c629
  Author: Bjorn Pettersson <bjorn.a.pettersson at ericsson.com>
  Date:   2021-06-02 (Wed, 02 Jun 2021)

  Changed paths:
    M llvm/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp

  Log Message:
  -----------
  [LegalizeTypes] Avoid promotion of exponent in FPOWI

The FPOWI DAG node is normally lowered to a libcall to one of the
RTLIB::POWI* runtime functions and the exponent should normally
have a type matching sizeof(int) when making the call. Thus,
type promotion of the exponent could lead to an FPOWI with a type
for the second operand that would be incorrect when doing the
libcall (a situation which would be hard to detect post-legalization
if we allow such FPOWI nodes).

This patch is changing DAGTypeLegalizer::PromoteIntOp_FPOWI to
do the rewrite into a libcall directly instead of promoting the
operand. This way we can check that the exponent is smaller than
sizeof(int) and we can let TargetLowering handle promotion as
part of making the libcall. It could be noticed here that makeLibCall
has some knowledge about targets such as 64-bit RISCV, for which the
libcall argument should be extended to a type larger than sizeof(int).

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


  Commit: 536e02a23c6555403a844810a42d2f32b7e59d63
      https://github.com/llvm/llvm-project/commit/536e02a23c6555403a844810a42d2f32b7e59d63
  Author: Bjorn Pettersson <bjorn.a.pettersson at ericsson.com>
  Date:   2021-06-02 (Wed, 02 Jun 2021)

  Changed paths:
    M llvm/include/llvm/CodeGen/RuntimeLibcalls.h
    M llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp
    M llvm/lib/CodeGen/SelectionDAG/LegalizeFloatTypes.cpp
    M llvm/lib/CodeGen/SelectionDAG/LegalizeIntegerTypes.cpp
    M llvm/lib/CodeGen/TargetLoweringBase.cpp

  Log Message:
  -----------
  [CodeGen] Refactor libcall lookups for RTLIB::POWI_*

Use RuntimeLibcalls to get a common way to pick correct RTLIB::POWI_*
libcall for a given value type.

This includes a small refactoring of ExpandFPLibCall and
ExpandArgFPLibCall in SelectionDAGLegalize to share a bit of code,
plus adding an ExpandFPLibCall version that can be called directly
when expanding FPOWI/STRICT_FPOWI to ensure that we actually use
the same RTLIB::Libcall when expanding the libcall as we used when
checking the legality of such a call by doing a getLibcallName check.

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


  Commit: fe208a4ef449d6e917dc5695ba793f4428980de3
      https://github.com/llvm/llvm-project/commit/fe208a4ef449d6e917dc5695ba793f4428980de3
  Author: Bjorn Pettersson <bjorn.a.pettersson at ericsson.com>
  Date:   2021-06-02 (Wed, 02 Jun 2021)

  Changed paths:
    A llvm/test/Transforms/InstCombine/pow_fp_int16.ll

  Log Message:
  -----------
  [InstCombine][msp430] Pre-commit test case for @llvm.powi and 16-bit ints

This is a pre-commit of a test case D99439 which is a patch that
updates @llvm.powi to handle different int sizes for the exponent.

Problem is that @llvm.powi is used as an IR construct that maps
to RT libcalls to __powi* functions, and those lib functions depend
on sizeof(int) to use correct type for the exponent.

The test cases show that we use i32 for the powi expenent, which
later would result in wrong type being used in libcalls (miscompile).

But there are also a couple of the negative test cases that show
that we rewrite into using powi when having a uitofp conversion
from i16, which would be wrong when doing the libcall as an
"unsigned int" isn't guaranteed to fit inside the "int" argument
in the called libcall function.

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


Compare: https://github.com/llvm/llvm-project/compare/942be7cb4d98...fe208a4ef449