[PATCH] D67923: [TLI] Support for per-Function TLI that overrides available libfuncs

Teresa Johnson via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 23 08:53:49 PDT 2019


tejohnson created this revision.
tejohnson added reviewers: chandlerc, hfinkel, gchatelet.
Herald added subscribers: dexonsmith, mehdi_amini.
Herald added a project: LLVM.

Follow-on to D66428 <https://reviews.llvm.org/D66428>, to help enable the TLI to be built per-function so
that -fno-builtin* handling can be migrated to use function attributes.
See discussion on D61634 <https://reviews.llvm.org/D61634> for background. This is an enabler for fixing
handling of these options for LTO, for example.

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. The draft code to support setting this
new array is ifdef'ed out as the builtins are not yet converted to
attributes.

I also added comments to indicate what we would want to do if the veclib
option was ever to be converted to a per-function attribute as well.

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 eventually 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.


Repository:
  rL LLVM

https://reviews.llvm.org/D67923

Files:
  include/llvm/Analysis/TargetLibraryInfo.h
  lib/Analysis/TargetLibraryInfo.cpp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D67923.221351.patch
Type: text/x-patch
Size: 9151 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20190923/8d1e47e1/attachment.bin>


More information about the llvm-commits mailing list