[WPD] Use new llvm.public.type.test intrinsic for potentially publicly visible classes

Turning on opaque pointers has uncovered an issue with WPD where we currently pattern match away `assume(type.t

[WPD] Use new llvm.public.type.test intrinsic for potentially publicly visible classes

Turning on opaque pointers has uncovered an issue with WPD where we currently pattern match away `assume(type.test)` in WPD so that a later LTT doesn't resolve the type test to undef and introduce an `assume(false)`. The pattern matching can fail in cases where we transform two `assume(type.test)`s into `assume(phi(type.test.1, type.test.2))`.

Currently we create `assume(type.test)` for all virtual calls that might be devirtualized. This is to support `-Wl,--lto-whole-program-visibility`.

To prevent this, all virtual calls that may not be in the same LTO module instead use a new `llvm.public.type.test` intrinsic in place of the `llvm.type.test`. Then when we know if `-Wl,--lto-whole-program-visibility` is passed or not, we can either replace all `llvm.public.type.test` with `llvm.type.test`, or replace all `llvm.public.type.test` with `true`. This prevents WPD from trying to pattern match away `assume(type.test)` for public virtual calls when failing the pattern matching will result in miscompiles.

Reviewed By: tejohnson

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

show more ...

[config] Remove vestigial LLVM_VERSION_INFO

This has been superseded by the llvm/Support/VCSRevision.h header. So
far as I can tell, nothing in the CMake build sets LLVM_VERSION_INFO. It
was always

[config] Remove vestigial LLVM_VERSION_INFO

This has been superseded by the llvm/Support/VCSRevision.h header. So
far as I can tell, nothing in the CMake build sets LLVM_VERSION_INFO. It
was always undefined, and the ifdefs using it were dead. However, CMake
is very flexible, so it's possible that I missed some ways to set this
variable. One could, for example, probably pass -DLLVM_VERSION_INFO=x on
the command line and get that through to configure_file, or set the
variable in an obscure way (`set(${proj}_VERSION_INFO "x")`). I'm
reasonably confident that isn't happening, but I'd like a second
opinion.

Update the Bazel and gn builds accordingly.

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

show more ...

[llvm] Use = default (NFC)

[llvm] Use range-based for loops (NFC)

[Support] Improve Caching conformance with Support library behavior

This diff makes several amendments to the local file caching mechanism
which was migrated from ThinLTO to Support in
rGe678c511771

[Support] Improve Caching conformance with Support library behavior

This diff makes several amendments to the local file caching mechanism
which was migrated from ThinLTO to Support in
rGe678c51177102845c93529d457b020f969125373 in response to follow-up
discussion on that commit.

Patch By: noajshu

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

show more ...

[Support][ThinLTO] Move ThinLTO caching to LLVM Support library

We would like to move ThinLTO’s battle-tested file caching mechanism to
the LLVM Support library so that we can use it elsewhere in LL

[Support][ThinLTO] Move ThinLTO caching to LLVM Support library

We would like to move ThinLTO’s battle-tested file caching mechanism to
the LLVM Support library so that we can use it elsewhere in LLVM.

Patch By: noajshu

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

show more ...

Revert "[Support][ThinLTO] Move ThinLTO caching to LLVM Support library"

This reverts commit 92b8cc52bbc8194f2cd6a5f742b874969421afca since
it broke the gold plugin.

[Support][ThinLTO] Move ThinLTO caching to LLVM Support library

We would like to move ThinLTO’s battle-tested file caching mechanism to
the LLVM Support library so that we can use it elsewhere in LL

[Support][ThinLTO] Move ThinLTO caching to LLVM Support library

We would like to move ThinLTO’s battle-tested file caching mechanism to
the LLVM Support library so that we can use it elsewhere in LLVM.

Patch By: noajshu

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

show more ...

Move TargetRegistry.(h|cpp) from Support to MC

This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually us

Move TargetRegistry.(h|cpp) from Support to MC

This moves the registry higher in the LLVM library dependency stack.
Every client of the target registry needs to link against MC anyway to
actually use the target, so we might as well move this out of Support.

This allows us to ensure that Support doesn't have includes from MC/*.

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

show more ...

Revert "[LTO][Legacy] Add -debug-pass-manager option to enable pass run/skip trace."

This reverts commit a60405cf035dc114e7ee090139bed2577f4ea7ef.

[LTO][Legacy] Add -debug-pass-manager option to enable pass run/skip trace.

Reviewed by: steven_wu, fhahn, tejohnson

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

[LTO][Legacy] Decouple option parsing from LTOCodeGenerator

in this patch we add a new libLTO API to specify debug options independent of an lto_code_gen_t.
This allows clients to pass codegen flags

[LTO][Legacy] Decouple option parsing from LTOCodeGenerator

in this patch we add a new libLTO API to specify debug options independent of an lto_code_gen_t.
This allows clients to pass codegen flags (through libLTO) which otherwise today are ignored.

Reviewed By: steven_wu

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

show more ...

[NFC] Reordering parameters in getFile and getFileOrSTDIN

In future patches I will be setting the IsText parameter frequently so I will refactor the args to be in the following order. I have removed

[NFC] Reordering parameters in getFile and getFileOrSTDIN

In future patches I will be setting the IsText parameter frequently so I will refactor the args to be in the following order. I have removed the FileSize parameter because it is never used.

```
static ErrorOr<std::unique_ptr<MemoryBuffer>>
getFile(const Twine &Filename, bool IsText = false,
bool RequiresNullTerminator = true, bool IsVolatile = false);

static ErrorOr<std::unique_ptr<MemoryBuffer>>
getFileOrSTDIN(const Twine &Filename, bool IsText = false,
bool RequiresNullTerminator = true);

static ErrorOr<std::unique_ptr<MB>>
getFileAux(const Twine &Filename, uint64_t MapSize, uint64_t Offset,
bool IsText, bool RequiresNullTerminator, bool IsVolatile);

static ErrorOr<std::unique_ptr<WritableMemoryBuffer>>
getFile(const Twine &Filename, bool IsVolatile = false);
```

Reviewed By: jhenderson

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

show more ...

Recommit "[LTO] Use lto::backend for code generation."

This version of the patch includes a fix for the cfi failures.

(undoes the revert commit 7db390cc7738a9ba0ed7d4ca59ab6ea2e69c47e9)

It also un

Recommit "[LTO] Use lto::backend for code generation."

This version of the patch includes a fix for the cfi failures.

(undoes the revert commit 7db390cc7738a9ba0ed7d4ca59ab6ea2e69c47e9)

It also undoes reverts of follow-up patches that also needed reverting
originally:

* [LTO] Add option enable NewPM with LTOCodeGenerator.
(undoes revert commit 0a17664b47c153aa26a0d31b4835f26375440ec6)

* [LTOCodeGenerator] Use lto::Config for options (NFC)."
(undoes revert commit b0a8e41cfff717ff067bf63412d6edb0280608cd)

show more ...

Revert "[LTO] Use lto::backend for code generation."

This reverts commit 6a59f0560648b43324b5aed51b9ef996404a25e0, because
it is causing failures on green dragon.

Revert "[LTO] Add option enable NewPM with LTOCodeGenerator."

This reverts commit 7a6a2cc81aaf064e6f5bc9a9a16973f552d2bdc2 because
it is causing failures on green dragon.

Revert "[LTOCodeGenerator] Use lto::Config for options (NFC)."

This reverts commit 0d487cf87aa1b609b7db061def3e5ad068576ecf because
it is causing failures on green dragon.

[LTOCodeGenerator] Use lto::Config for options (NFC).

This patch removes some options that have been duplicated in
LTOCodeGenerator and instead use lto::Config directly to manage the
options.

This

[LTOCodeGenerator] Use lto::Config for options (NFC).

This patch removes some options that have been duplicated in
LTOCodeGenerator and instead use lto::Config directly to manage the
options.

This is a cleanup after 6a59f0560648.

Reviewed By: tejohnson

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

show more ...

[LTO] Add option enable NewPM with LTOCodeGenerator.

This patch adds an option to enable the new pass manager in
LTOCodeGenerator. It also updates a few tests with legacy PM specific
tests, which st

[LTO] Add option enable NewPM with LTOCodeGenerator.

This patch adds an option to enable the new pass manager in
LTOCodeGenerator. It also updates a few tests with legacy PM specific
tests, which started failing after 6a59f0560648 when
LLVM_ENABLE_NEW_PASS_MANAGER=true.

show more ...

[LTO] Use lto::backend for code generation.

This patch updates LTOCodeGenerator to use the utilities provided by
LTOBackend to run middle-end optimizations and backend code generation.

This is a fi

[LTO] Use lto::backend for code generation.

This patch updates LTOCodeGenerator to use the utilities provided by
LTOBackend to run middle-end optimizations and backend code generation.

This is a first step towards unifying the code used by libLTO's C API
and the newer, C++ interface (see PR41541).

The immediate motivation is to allow using the new pass manager when
doing LTO using libLTO's C API, which is used on Darwin, among others.

With the changes, there are no codegen/stats differences when building
MultiSource/SPEC2000/SPEC2006 on Darwin X86 with LTO, compared
to without the patch.

Reviewed By: steven_wu

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

show more ...

[LTO] Update splitCodeGen to take a reference to the module. (NFC)

splitCodeGen does not need to take ownership of the module, as it
currently clones the original module for each split operation.

T

[LTO] Update splitCodeGen to take a reference to the module. (NFC)

splitCodeGen does not need to take ownership of the module, as it
currently clones the original module for each split operation.

There is an ~4 year old fixme to change that, but until this is
addressed, the function can just take a reference to the module.

This makes the transition of LTOCodeGenerator to use LTOBackend a bit
easier, because under some circumstances, LTOCodeGenerator needs to
write the original module back after codegen.

Reviewed By: tejohnson

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

show more ...

[LTO] Prevent devirtualization for symbols dynamically exported

Identify dynamically exported symbols (--export-dynamic[-symbol=],
--dynamic-list=, or definitions needed to preempt shared objects) a

[LTO] Prevent devirtualization for symbols dynamically exported

Identify dynamically exported symbols (--export-dynamic[-symbol=],
--dynamic-list=, or definitions needed to preempt shared objects) and
prevent their LTO visibility from being upgraded.
This helps avoid use of whole program devirtualization when there may
be overrides in dynamic libraries.

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

show more ...

[LTO] Move DisableVerify setting to LTOCodeGenerator class (NFC).

To simplify the transition to using LTOBackend, move DisableVerify to
the LTOCodeGenerator class, like most/all other options.

Revi

[LTO] Move DisableVerify setting to LTOCodeGenerator class (NFC).

To simplify the transition to using LTOBackend, move DisableVerify to
the LTOCodeGenerator class, like most/all other options.

Reviewed By: tejohnson

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

show more ...

[LTO] Store target attributes as vector of strings (NFC).

The target features are obtained as a list of features/attributes.
Instead of storing them in a single string, store the vector. This
matche

[LTO] Store target attributes as vector of strings (NFC).

The target features are obtained as a list of features/attributes.
Instead of storing them in a single string, store the vector. This
matches lto::Config's behavior and simplifies the transition to
lto::backend().

Reviewed By: tejohnson

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

show more ...

[LTO] Remove options to disable inlining, vectorization & GVNLoadPRE.

This patch removes some ancient options as a clean-up before moving
code-gen to use LTOBackend in D94487.

I think it would pref

[LTO] Remove options to disable inlining, vectorization & GVNLoadPRE.

This patch removes some ancient options as a clean-up before moving
code-gen to use LTOBackend in D94487.

I think it would preferable to remove those ancient options, because

1. There are no corresponding options in LTOBackend based tools,
2. There are no unit tests for them,
3. They are not passed through by Clang,
4. At least for GNVLoadPRE, users could just use GVN's `enable-load-pre`.

Alternatively we could add support for those options to lto::Config &
co, but I think it would be better to remove them, unless they are
actually used in practice.

Reviewed By: steven_wu, tejohnson

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

show more ...