[all-commits] [llvm/llvm-project] 878ab6: [TLI] Support for per-Function TLI that overrides ...

[Teresa Johnson via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 878ab6df033d44430939c02075ee00800995dc3b
      https://github.com/llvm/llvm-project/commit/878ab6df033d44430939c02075ee00800995dc3b
  Author: Teresa Johnson <tejohnson at google.com>
  Date:   2019-12-16 (Mon, 16 Dec 2019)

  Changed paths:
    M clang/lib/CodeGen/BackendUtil.cpp
    M llvm/include/llvm/Analysis/TargetLibraryInfo.h
    M llvm/lib/Analysis/TargetLibraryInfo.cpp

  Log Message:
  -----------
  [TLI] Support for per-Function TLI that overrides available libfuncs

Summary:

Follow-on to D66428 and D71193, to build the TLI per-function so
that -fno-builtin* handling can be migrated to use function attributes.
See discussion on D61634 for background. This is an enabler for fixing
handling of these options for LTO, for example.

With D71193, the -fno-builtin* flags are converted to function
attributes, so we can now set this information per-function on the TLI.

In this patch, the TLI constructor is changed to take a Function, which
can be used to override the available builtins. The TLI is augmented
with an array that can be used to specify which builtins are not
available for the corresponding function. The available function checks
are changed to consult this override before checking the underlying
module level baseline TLII. New code is added to set this override
array based on the attributes.

I also removed the code that sets availability in the TLII in clang from
the options, which is no longer needed.

I removed a per-Triple caching of TLII objects in the analysis object,
as it is based on the Module's Triple which is the same for all
functions in any case. Is there a case where we would be compiling
multiple Modules with different Triples in one compilation?

Finally, I have changed the legacy analysis wrapper to create and use
the new PM analysis class (TargetLibraryAnalysis) in getTLI. This is
consistent with the behavior of getTTI for the legacy
TargetTransformInfo analysis. This change means that getTLI now creates
a new TLI on each call (although that should be very cheap as we cache
the module level TLII, and computing the per-function
attribute based availability should also be reasonably efficient).
I measured the compile time for a large C++ file with tens of thousands
of functions and as expected there was no increase.

Reviewers: chandlerc, hfinkel, gchatelet

Subscribers: mehdi_amini, dexonsmith, llvm-commits

Tags: #llvm

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