[all-commits] [llvm/llvm-project] 66fcdf: [Analysis][SimplifyLibCalls] Refactor code related...

[Björn Pettersson via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 66fcdfca4d4587fcf93e15859e330ce5d671de82
      https://github.com/llvm/llvm-project/commit/66fcdfca4d4587fcf93e15859e330ce5d671de82
  Author: Bjorn Pettersson <bjorn.a.pettersson at ericsson.com>
  Date:   2022-10-03 (Mon, 03 Oct 2022)

  Changed paths:
    M llvm/include/llvm/Analysis/TargetLibraryInfo.h
    M llvm/lib/Analysis/TargetLibraryInfo.cpp
    M llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp

  Log Message:
  -----------
  [Analysis][SimplifyLibCalls] Refactor code related to size_t in lib func signatures. NFC

Added a helper in TargetLibraryInfo to get size of "size_t" in bits,
given a Module reference. The new getSizeTSize helper is using the
same strategy as for example isValidProtoForLibFunc has been using
in the past, assuming that the size can be derived by asking
DataLayout about the size/type of a pointer to int.

FortifiedLibCallSimplifier::optimizeStrpCpyChk was changed to use
the new getSizeTSize helper instead of assuming that sizeof(size_t)
is equal to sizeof(int*) by itself (that is the assumption used in
TargetLibraryInfoImpl::getSizeTSize so the result will be the same).

Having a common helper for this ensure that we use the same strategy
when deriving the size of "size_t" in different parts of the code.
One bonus with this refactoring (basing it on Module instead of just
DataLayout) is that it makes it easier to override this for a specific
target triple, in case the assumption of using getPointerSizeInBits
wouldn't hold.

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