[ThinLTO] Don't import GV which contains blockaddress

Differential revision: https://reviews.llvm.org/D53139

llvm-svn: 344325

[WPD] Fix incorrect devirtualization after indirect call promotion

Summary:
Add a dominance check to ensure that the possible devirtualizable
call is actually dominated by the type test/checked load

[WPD] Fix incorrect devirtualization after indirect call promotion

Summary:
Add a dominance check to ensure that the possible devirtualizable
call is actually dominated by the type test/checked load intrinsic being
analyzed. With PGO, after indirect call promotion is performed during
the compile step, followed by inlining, we may have a type test in the
promoted and inlined sequence that allows an indirect call in that
sequence to be devirtualized. That indirect call (inserted by inlining
after promotion) will share the same vtable pointer as the fallback
indirect call that cannot be devirtualized.

Before this patch the code was incorrectly devirtualizing the fallback
indirect call.

See the new test and the example described there for more details.

Reviewers: pcc, vitalybuka

Subscribers: mehdi_amini, Prazek, eraman, steven_wu, dexonsmith, llvm-commits

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

llvm-svn: 343226

show more ...

[ThinLTO] Add string saver onto index for value names

Summary:
Adds a string saver to the ModuleSummaryIndex so it can store value
names in the case of adding a ValueInfo for a GUID when we don't
ha

[ThinLTO] Add string saver onto index for value names

Summary:
Adds a string saver to the ModuleSummaryIndex so it can store value
names in the case of adding a ValueInfo for a GUID when we don't
have the name stored in a Module string table. This is motivated
by the upcoming summary parser patch, where we will read value names
from the summary entry and want to store them, even when a Module
is not available.

Currently this allows us to store the name in the legacy bitcode case,
and I have added a test to show that.

Reviewers: pcc, dexonsmith

Subscribers: mehdi_amini, inglorion, eraman, steven_wu, llvm-commits

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

llvm-svn: 335570

show more ...

[ThinLTO] Compute GUID directly from GV when building per-module index

Summary:
I discovered when writing the summary parsing support that the
per-module index builder and writer are computing the G

[ThinLTO] Compute GUID directly from GV when building per-module index

Summary:
I discovered when writing the summary parsing support that the
per-module index builder and writer are computing the GUID from the
value name alone (ignoring the linkage type). This was ok since those
GUID were not emitted in the bitcode, and there are never multiple
conflicting names in a single module.

However, I don't see a reason for making the GUID computation different
for the per-module case. It also makes things simpler on the parsing
side to have the GUID computation consistent. So this patch changes the
summary analysis phase and the per-module summary writer to compute the
GUID using the facility on the GlobalValue.

Reviewers: pcc, dexonsmith

Subscribers: llvm-commits, inglorion

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

llvm-svn: 335560

show more ...

[ThinLTO] Rename index IsAnalysis flag to HaveGVs (NFC)

With the upcoming patch to add summary parsing support, IsAnalysis would
be true in contexts where we are not performing module summary analys

[ThinLTO] Rename index IsAnalysis flag to HaveGVs (NFC)

With the upcoming patch to add summary parsing support, IsAnalysis would
be true in contexts where we are not performing module summary analysis.
Rename to the more specific and approprate HaveGVs, which is essentially
what this flag is indicating.

llvm-svn: 334140

show more ...

[ThinLTO] Add an option to force summary call edges cold for debugging

Summary:
Useful to selectively disable importing into specific modules for
debugging/triaging/workarounds.

Reviewers: eraman

[ThinLTO] Add an option to force summary call edges cold for debugging

Summary:
Useful to selectively disable importing into specific modules for
debugging/triaging/workarounds.

Reviewers: eraman

Subscribers: inglorion, llvm-commits

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

llvm-svn: 328909

show more ...

[ThinLTO] Add funtions in callees metadata to CallGraphEdges

Summary:
If there's a callees metadata attached to the indirect call instruction, add CallGraphEdges to the callees mentioned in the meta

[ThinLTO] Add funtions in callees metadata to CallGraphEdges

Summary:
If there's a callees metadata attached to the indirect call instruction, add CallGraphEdges to the callees mentioned in the metadata when computing FunctionSummary.

* Why this is necessary:
Consider following code example:
```
(foo.c)
static int f1(int x) {...}
static int f2(int x);
static int (*fptr)(int) = f2;
static int f2(int x) {
if (x) fptr=f1; return f1(x);
}
int foo(int x) {
(*fptr)(x); // !callees metadata of !{i32 (i32)* @f1, i32 (i32)* @f2} would be attached to this call.
}

(bar.c)
int bar(int x) {
return foo(x);
}
```

At LTO time when `foo.o` is imported into `bar.o`, function `foo` might be inlined into `bar` and PGO-guided indirect call promotion will run after that. If the profile data tells that the promotion of `@f1` or `@f2` is beneficial, the optimizer will check if the "promoted" `@f1` or `@f2` (such as `@f1.llvm.0` or `@f2.llvm.0`) is available. Without this patch, importing `!callees` metadata would only add promoted declarations of `@f1` and `@f2` to the `bar.o`, but still the optimizer will assume that the function is available and perform the promotion. The result of that is link failure with `undefined reference to @f1.llvm.0`.

This patch fixes this problem by adding callees in the `!callees` metadata to CallGraphEdges so that their definition would be properly imported into.

One may ask that there already is a logic to add indirect call promotion targets to be added to CallGraphEdges. However, if profile data says "indirect call promotion is only beneficial under a certain inline context", the logic wouldn't work. In the code example above, if profile data is like
```
bar:1000000:100000
1:100000
1: foo:100000
1: 100000 f1:100000
```
, Computing FunctionSummary for `foo.o` wouldn't add `foo->f1` to CallGraphEdges. (Also, it is at least "possible" that one can provide profile data to only link step but not to compilation step).

Reviewers: tejohnson, mehdi_amini, pcc

Reviewed By: tejohnson

Subscribers: inglorion, eraman, llvm-commits

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

llvm-svn: 327358

show more ...

[ThinLTO] Represent relative BF using a scaled representation .

Summary:
The current integer representation of relative block frequency prevents
representing relative block frequencies below 1. This

[ThinLTO] Represent relative BF using a scaled representation .

Summary:
The current integer representation of relative block frequency prevents
representing relative block frequencies below 1. This change uses a 8 of
the 29 bits to represent the decimal part by using a fixed scale of -8.

Reviewers: tejohnson, davidxl

Subscribers: mehdi_amini, inglorion, llvm-commits

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

llvm-svn: 325823

show more ...

Re-land "[ThinLTO] Add call edges' relative block frequency to per-module summary."

It was reverted after buildbot regressions.

Original commit message:

This allows relative block frequency of cal

Re-land "[ThinLTO] Add call edges' relative block frequency to per-module summary."

It was reverted after buildbot regressions.

Original commit message:

This allows relative block frequency of call edges to be passed
to the thinlink stage where it will be used to compute synthetic
entry counts of functions.

llvm-svn: 323460

show more ...

Revert "[ThinLTO] Add call edges' relative block frequency to per-module summary."

Causes buildbot regressions.

llvm-svn: 323358

[ThinLTO] Add call edges' relative block frequency to per-module summary.

Summary:
This allows relative block frequency of call edges to be passed to the
thinlink stage where it will be used to comp

[ThinLTO] Add call edges' relative block frequency to per-module summary.

Summary:
This allows relative block frequency of call edges to be passed to the
thinlink stage where it will be used to compute synthetic entry counts
of functions.

Reviewers: tejohnson, pcc

Subscribers: mehdi_amini, llvm-commits, inglorion

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

llvm-svn: 323349

show more ...

[ThinLTO] Re-commit of dot dumper after test fix

llvm-svn: 323116

Temporarily revert r323062 to investigate buildbot failures

llvm-svn: 323065

[ThinLTO] Implement summary visualizer

Differential revision: https://reviews.llvm.org/D41297

llvm-svn: 323062

[ThinLTO] Don't import functions with noinline attribute

Differential revision: https://reviews.llvm.org/D41489

llvm-svn: 321443

Add hasProfileData() to check if a function has profile data. NFC.

Summary:
This replaces calls to getEntryCount().hasValue() with hasProfileData
that does the same thing. This refactoring is useful

Add hasProfileData() to check if a function has profile data. NFC.

Summary:
This replaces calls to getEntryCount().hasValue() with hasProfileData
that does the same thing. This refactoring is useful to do before adding
synthetic function entry counts but also a useful cleanup IMO even
otherwise. I have used hasProfileData instead of hasRealProfileData as
David had earlier suggested since I think profile implies "real" and I
use the phrase "synthetic entry count" and not "synthetic profile count"
but I am fine calling it hasRealProfileData if you prefer.

Reviewers: davidxl, silvas

Subscribers: llvm-commits

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

llvm-svn: 321331

show more ...

[ThinLTO] Remove too aggressive assertion in building function call graph.

The assertion was introduced in r317853 but there are cases when a call
isn't handled either as direct or indirect. In this

[ThinLTO] Remove too aggressive assertion in building function call graph.

The assertion was introduced in r317853 but there are cases when a call
isn't handled either as direct or indirect. In this case we add a
reference graph edge but not a call graph edge.

Reviewers: tejohnson

Reviewed By: tejohnson

Subscribers: mehdi_amini, inglorion, eraman, hiraditya, efriedma, llvm-commits

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

llvm-svn: 318540

show more ...

[ThinLTO] Fix missing call graph edges for calls with bitcasts.

This change doesn't fix the root cause of the miscompile PR34966 as the root
cause is in the linker ld64. This change makes call graph

[ThinLTO] Fix missing call graph edges for calls with bitcasts.

This change doesn't fix the root cause of the miscompile PR34966 as the root
cause is in the linker ld64. This change makes call graph more complete
allowing to have better module imports/exports.

rdar://problem/35344706

Reviewers: tejohnson

Reviewed By: tejohnson

Subscribers: mehdi_amini, inglorion, eraman, llvm-commits, hiraditya

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

llvm-svn: 317853

show more ...

[LTO][ThinLTO] Use the linker resolutions to mark global values as dso_local.

Now that we have a way to mark GlobalValues as local we can use the symbol
resolutions that the linker plugin provides a

[LTO][ThinLTO] Use the linker resolutions to mark global values as dso_local.

Now that we have a way to mark GlobalValues as local we can use the symbol
resolutions that the linker plugin provides as part of lto/thinlto link
step to refine the compilers view on what symbols will end up being local.

Originally commited as r317374, but reverted in r317395 to update some missed
tests.

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

llvm-svn: 317408

show more ...

Revert "[LTO][ThinLTO] Use the linker resolutions to mark global values ..."

Changes more tests then expected on one of the build bots.
reverting to investigate.

This reverts https://llvm.org/svn/l

Revert "[LTO][ThinLTO] Use the linker resolutions to mark global values ..."

Changes more tests then expected on one of the build bots.
reverting to investigate.

This reverts https://llvm.org/svn/llvm-project/llvm/trunk@317374

llvm-svn: 317395

show more ...

[LTO][ThinLTO] Use the linker resolutions to mark global values as dso_local.

Now that we have a way to mark GlobalValues as local we can use the symbol
resolutions that the linker plugin provides a

[LTO][ThinLTO] Use the linker resolutions to mark global values as dso_local.

Now that we have a way to mark GlobalValues as local we can use the symbol
resolutions that the linker plugin provides as part of lto/thinlto link
step to refine the compilers view on what symbols will end up being local.

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

llvm-svn: 317374

show more ...

[ThinLTO] AliasSummary should not have any references

Summary: References should only be on the aliasee.

Reviewers: pcc

Subscribers: llvm-commits, inglorion

Differential Revision: https://reviews

[ThinLTO] AliasSummary should not have any references

Summary: References should only be on the aliasee.

Reviewers: pcc

Subscribers: llvm-commits, inglorion

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

llvm-svn: 313158

show more ...

ModuleSummaryAnalysis: Correctly handle all function operand references.

The current code that handles personality functions when creating a
module summary does not correctly handle the case where a

ModuleSummaryAnalysis: Correctly handle all function operand references.

The current code that handles personality functions when creating a
module summary does not correctly handle the case where a function's
personality function operand refers to the function indirectly
(e.g. via a bitcast). This patch handles such cases by treating
personality function references like any other reference, i.e. by
adding them to the function's reference list. This has the minor side
benefit of allowing personality functions to participate in early
dead stripping.

We do this by calling findRefEdges on the function itself. This way
we also end up handling other function operands (specifically prefix
data and prologue data) for free.

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

llvm-svn: 312698

show more ...

ModuleSummaryAnalysis: Correctly handle refs from function inline asm to module inline asm.

If a function contains inline asm and the module-level inline asm
contains the definition of a local symbo

ModuleSummaryAnalysis: Correctly handle refs from function inline asm to module inline asm.

If a function contains inline asm and the module-level inline asm
contains the definition of a local symbol, prevent the function from
being imported in case the function-level inline asm refers to a
symbol in the module-level inline asm.

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

llvm-svn: 312332

show more ...

[lib/Analysis] - Mark personality functions as live.

This is PR33245.

Case I am fixing is next:
Imagine we have 2 BC files, one defines and uses personality routine,
second has only declaration and

[lib/Analysis] - Mark personality functions as live.

This is PR33245.

Case I am fixing is next:
Imagine we have 2 BC files, one defines and uses personality routine,
second has only declaration and also uses it.

Previously algorithm computing dead symbols (llvm::computeDeadSymbols) did
not know about personality routines and leaved them dead even if function that
has routine was live.

As a result thinLTOInternalizeAndPromoteGUID() method changed binding for
such symbol to local. Later when LLD tried to link these objects it failed
because one object had undefined global symbol for routine and second
object contained local definition instead of global.

Patch set the live root flag on the corresponding FunctionSummary
for personality routines when we build the per-module summaries
during the compile step.

Differential revision: https://reviews.llvm.org/D36834

llvm-svn: 311432

show more ...