[clang] Don't emit type test/assume for virtual classes that should never participate in WPD

Reviewed By: pcc

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

Use llvm::append_range instead of push_back loops where applicable. NFCI.

[clang] Remove Address::deprecated() calls in CGVTables.cpp

[CodeGen] Rename deprecated Address constructor

To make uses of the deprecated constructor easier to spot, and to
ensure that no new uses are introduced, rename it to
Address::deprecated().

While d

[CodeGen] Rename deprecated Address constructor

To make uses of the deprecated constructor easier to spot, and to
ensure that no new uses are introduced, rename it to
Address::deprecated().

While doing the rename, I've filled in element types in cases
where it was relatively obvious, but we're still left with 135
calls to the deprecated constructor.

show more ...

[clang] Use true/false instead of 1/0 (NFC)

Identified with modernize-use-bool-literals.

[OpenMP] Remove doing assumption propagation in the front end.

This patch removes the assumption propagation that was added in D110655
primarily to get assumption informatino on opaque call sites fo

[OpenMP] Remove doing assumption propagation in the front end.

This patch removes the assumption propagation that was added in D110655
primarily to get assumption informatino on opaque call sites for
optimizations. The analysis done in D111445 allows us to do this more
intelligently in the back-end.

Depends on D111445

Reviewed By: jdoerfert

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

show more ...

[clang] Use llvm::{count,count_if,find_if,all_of,none_of} (NFC)

[OpenMP] Apply OpenMP assumptions to applicable call sites

This patch adds OpenMP assumption attributes to call sites in applicable
regions. Currently this applies the caller's assumption attributes

[OpenMP] Apply OpenMP assumptions to applicable call sites

This patch adds OpenMP assumption attributes to call sites in applicable
regions. Currently this applies the caller's assumption attributes to
any calls contained within it. So, if a call occurs inside an OpenMP
assumes region to a function outside that region, we will assume that
call respects the assumptions. This is primarily useful for inline
assembly calls used heavily in the OpenMP GPU device runtime, which
allows us to then make judgements about what the ASM will do.

Reviewed By: jdoerfert

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

show more ...

[Clang][Codegen] Do not annotate thunk's this/return types with align/deref/nonnull attrs

As it was discovered in post-commit feedback
for 0aa0458f1429372038ca6a4edc7e94c96cd9a753,
we handle thunks

[Clang][Codegen] Do not annotate thunk's this/return types with align/deref/nonnull attrs

As it was discovered in post-commit feedback
for 0aa0458f1429372038ca6a4edc7e94c96cd9a753,
we handle thunks incorrectly, and end up annotating
their this/return with attributes that are valid
for their callees, not for thunks themselves.

While it would be good to fix this properly,
and keep annotating them on thunks,
i've tried doing that in https://reviews.llvm.org/D100388
with little success, and the patch is stuck for a month now.

So for now, as a stopgap measure, subj.

show more ...

[NFCI][clang][Codegen] CodeGenVTables::addVTableComponent(): use getGlobalDecl

It does the same thing.
Split off from https://reviews.llvm.org/D100388

[clang][RelativeVTablesABI] Use dso_local_equivalent rather than emitting stubs

Thanks to D77248, we can bypass the use of stubs altogether and use PLT
relocations if they are available for the targ

[clang][RelativeVTablesABI] Use dso_local_equivalent rather than emitting stubs

Thanks to D77248, we can bypass the use of stubs altogether and use PLT
relocations if they are available for the target. LLVM and LLD support the
R_AARCH64_PLT32 relocation, so we can also guarantee a static PLT relocation on AArch64.
Not emitting these stubs saves a lot of extra binary size.

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

show more ...

Avoid redundant work when computing vtable vcall visibility

Add a Visited set to avoid repeatedly processing the same base classes
in complex class hierarchies. This cut down the compile time of one

Avoid redundant work when computing vtable vcall visibility

Add a Visited set to avoid repeatedly processing the same base classes
in complex class hierarchies. This cut down the compile time of one
source file from >12min to ~1min.

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

show more ...

[CodeGen] Store the return value of the target function call to the
thunk's return value slot directly when the return type is an aggregate
instead of doing so via a temporary

This fixes PR45997 (ht

[CodeGen] Store the return value of the target function call to the
thunk's return value slot directly when the return type is an aggregate
instead of doing so via a temporary

This fixes PR45997 (https://bugs.llvm.org/show_bug.cgi?id=45997), which
is caused by a bug that has existed since we started passing and
returning C++ structs with ObjC strong pointer members (see
https://reviews.llvm.org/D44908) or structs annotated with trivial_abi
directly.

rdar://problem/63740936

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

show more ...

[clang] Frontend components for the relative vtables ABI (round 2)

This patch contains all of the clang changes from D72959.

- Generalize the relative vtables ABI such that it can be used by other

[clang] Frontend components for the relative vtables ABI (round 2)

This patch contains all of the clang changes from D72959.

- Generalize the relative vtables ABI such that it can be used by other targets.
- Add an enum VTableComponentLayout which controls whether components in the
vtable should be pointers to other structs or relative offsets to those structs.
Other ABIs can change this enum to restructure how components in the vtable
are laid out/accessed.
- Add methods to ConstantInitBuilder for inserting relative offsets to a
specified position in the aggregate being constructed.
- Fix failing tests under new PM and ASan and MSan issues.

See D72959 for background info.

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

show more ...

Revert "[clang] Frontend components for the relative vtables ABI"

This reverts commit 2e009dbcb3e373a59e6e84dce6d51ae8a29f60a5.

Reverting since there were some test failures on buildbots that used

Revert "[clang] Frontend components for the relative vtables ABI"

This reverts commit 2e009dbcb3e373a59e6e84dce6d51ae8a29f60a5.

Reverting since there were some test failures on buildbots that used the
new pass manager. ASan and MSan are also finding some bugs in this that
I'll need to address.

show more ...

[clang] Frontend components for the relative vtables ABI

This patch contains all of the clang changes from D72959.

- Generalize the relative vtables ABI such that it can be used by other targets.
-

[clang] Frontend components for the relative vtables ABI

This patch contains all of the clang changes from D72959.

- Generalize the relative vtables ABI such that it can be used by other targets.
- Add an enum VTableComponentLayout which controls whether components in the
vtable should be pointers to other structs or relative offsets to those structs.
Other ABIs can change this enum to restructure how components in the vtable
are laid out/accessed.
- Add methods to ConstantInitBuilder for inserting relative offsets to a
specified position in the aggregate being constructed.

See D72959 for background info.

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

show more ...

[CodeGen] Emit destructor calls to destruct non-trivial C struct objects
returned by function calls or loaded from volatile objects

rdar://problem/51867864

Differential Revision: https://reviews.ll

[CodeGen] Emit destructor calls to destruct non-trivial C struct objects
returned by function calls or loaded from volatile objects

rdar://problem/51867864

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

show more ...

Use FinishThunk to finish musttail thunks

FinishThunk, and the invariant of setting and then unsetting
CurCodeDecl, was added in 7f416cc42638 (2015). The invariant didn't
exist when I added this mus

Use FinishThunk to finish musttail thunks

FinishThunk, and the invariant of setting and then unsetting
CurCodeDecl, was added in 7f416cc42638 (2015). The invariant didn't
exist when I added this musttail codepath in ab2090d10765 (2014).
Recently in 28328c3771, I started using this codepath on non-Windows
platforms, and users reported problems during release testing (PR44987).

The issue was already present for users of EH on i686-windows-msvc, so I
added a test for that case as well.

Reviewed By: hans

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

show more ...

Restore "[LTO/WPD] Enable aggressive WPD under LTO option"

This restores 59733525d37cf9ad88b5021b33ecdbaf2e18911c (D71913), along
with bot fix 19c76989bb505c3117730c47df85fd3800ea2767.

The bot fail

Restore "[LTO/WPD] Enable aggressive WPD under LTO option"

This restores 59733525d37cf9ad88b5021b33ecdbaf2e18911c (D71913), along
with bot fix 19c76989bb505c3117730c47df85fd3800ea2767.

The bot failure should be fixed by D73418, committed as
af954e441a5170a75687699d91d85e0692929d43.

I also added a fix for non-x86 bot failures by requiring x86 in new test
lld/test/ELF/lto/devirt_vcall_vis_public.ll.

show more ...

Revert "[LTO/WPD] Enable aggressive WPD under LTO option"

This reverts commit 59733525d37cf9ad88b5021b33ecdbaf2e18911c.

There is a windows sanitizer bot failure in one of the cfi tests
that I will

Revert "[LTO/WPD] Enable aggressive WPD under LTO option"

This reverts commit 59733525d37cf9ad88b5021b33ecdbaf2e18911c.

There is a windows sanitizer bot failure in one of the cfi tests
that I will need some time to figure out:
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/57155/steps/stage%201%20check/logs/stdio

show more ...

[LTO/WPD] Enable aggressive WPD under LTO option

Summary:
Third part in series to support Safe Whole Program Devirtualization
Enablement, see RFC here:
http://lists.llvm.org/pipermail/llvm-dev/2019-

[LTO/WPD] Enable aggressive WPD under LTO option

Summary:
Third part in series to support Safe Whole Program Devirtualization
Enablement, see RFC here:
http://lists.llvm.org/pipermail/llvm-dev/2019-December/137543.html

This patch adds type test metadata under -fwhole-program-vtables,
even for classes without hidden visibility. It then changes WPD to skip
devirtualization for a virtual function call when any of the compatible
vtables has public vcall visibility.

Additionally, internal LLVM options as well as lld and gold-plugin
options are added which enable upgrading all public vcall visibility
to linkage unit (hidden) visibility during LTO. This enables the more
aggressive WPD to kick in based on LTO time knowledge of the visibility
guarantees.

Support was added to all flavors of LTO WPD (regular, hybrid and
index-only), and to both the new and old LTO APIs.

Unfortunately it was not simple to split the first and second parts of
this part of the change (the unconditional emission of type tests and
the upgrading of the vcall visiblity) as I needed a way to upgrade the
public visibility on legacy WPD llvm assembly tests that don't include
linkage unit vcall visibility specifiers, to avoid a lot of test churn.

I also added a mechanism to LowerTypeTests that allows dropping type
test assume sequences we now aggressively insert when we invoke
distributed ThinLTO backends with null indexes, which is used in testing
mode, and which doesn't invoke the normal ThinLTO backend pipeline.

Depends on D71907 and D71911.

Reviewers: pcc, evgeny777, steven_wu, espindola

Subscribers: emaste, Prazek, inglorion, arichardson, hiraditya, MaskRay, dexonsmith, dang, davidxl, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

show more ...

[WPD/VFE] Always emit vcall_visibility metadata for -fwhole-program-vtables

Summary:
First patch to support Safe Whole Program Devirtualization Enablement,
see RFC here: http://lists.llvm.org/piperm

[WPD/VFE] Always emit vcall_visibility metadata for -fwhole-program-vtables

Summary:
First patch to support Safe Whole Program Devirtualization Enablement,
see RFC here: http://lists.llvm.org/pipermail/llvm-dev/2019-December/137543.html

Always emit !vcall_visibility metadata under -fwhole-program-vtables,
and not just for -fvirtual-function-elimination. The vcall visibility
metadata will (in a subsequent patch) be used to communicate to WPD
which vtables are safe to devirtualize, and we will optionally convert
the metadata to hidden visibility at link time. Subsequent follow on
patches will help enable this by adding vcall_visibility metadata to the
ThinLTO summaries, and always emit type test intrinsics under
-fwhole-program-vtables (and not just for vtables with hidden
visibility).

In order to do this safely with VFE, since for VFE all vtable loads must
be type checked loads which will no longer be the case, this patch adds
a new "Virtual Function Elim" module flag to communicate to GlobalDCE
whether to perform VFE using the vcall_visibility metadata.

One additional advantage of using the vcall_visibility metadata to drive
more WPD at LTO link time is that we can use the same mechanism to
enable more aggressive VFE at LTO link time as well. The link time
option proposed in the RFC will convert vcall_visibility metadata to
hidden (aka linkage unit visibility), which combined with
-fvirtual-function-elimination will allow it to be done more
aggressively at LTO link time under the same conditions.

Reviewers: pcc, ostannard, evgeny777, steven_wu

Subscribers: mehdi_amini, Prazek, hiraditya, dexonsmith, davidxl, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

show more ...

[OPENMP]Do not emit special virtual function for NVPTX target.

There are no special virtual function handlers (like __cxa_pure_virtual)
defined for NVPTX target, so just emit such functions as null

[OPENMP]Do not emit special virtual function for NVPTX target.

There are no special virtual function handlers (like __cxa_pure_virtual)
defined for NVPTX target, so just emit such functions as null pointers
to prevent issues with linking and unresolved references.

show more ...

Fix "pointer is null" static analyzer warning. NFCI.

Use castAs<> instead of getAs<> since the pointer is dereferenced immediately below and castAs will perform the null assertion for us.

Avoid Attr.h includes, CodeGen edition

This saves around 20 includes of Attr.h. Not much.