[IR] Enable opaque pointers by default

This enabled opaque pointers by default in LLVM. The effect of this
is twofold:

* If IR that contains *neither* explicit ptr nor %T* types is passed
to tool

[IR] Enable opaque pointers by default

This enabled opaque pointers by default in LLVM. The effect of this
is twofold:

* If IR that contains *neither* explicit ptr nor %T* types is passed
to tools, we will now use opaque pointer mode, unless
-opaque-pointers=0 has been explicitly passed.
* Users of LLVM as a library will now default to opaque pointers.
It is possible to opt-out by calling setOpaquePointers(false) on
LLVMContext.

A cmake option to toggle this default will not be provided. Frontends
or other tools that want to (temporarily) keep using typed pointers
should disable opaque pointers via LLVMContext.

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

show more ...

Make GlobalValues with non-default visibilility dso_local.

This is similar to r322317, but for visibility. It is not as neat
because we have to special case extern_weak.

The idea is the same as the

Make GlobalValues with non-default visibilility dso_local.

This is similar to r322317, but for visibility. It is not as neat
because we have to special case extern_weak.

The idea is the same as the previous change, make the transition to
explicit dso_local easier for the frontends. With this they only have
to add dso_local to symbols where we need some external information to
decide if it is dso_local (like it being part of an ELF executable).

llvm-svn: 322806

show more ...

Make internal/private GVs implicitly dso_local.

While updating clang tests for having clang set dso_local I noticed
that:

- There are *a lot* of tests to update.
- Many of the updates are redundant

Make internal/private GVs implicitly dso_local.

While updating clang tests for having clang set dso_local I noticed
that:

- There are *a lot* of tests to update.
- Many of the updates are redundant.

They are redundant because a GV is "obviously dso_local". This patch
starts formalizing that a bit by requiring that internal and private
GVs be dso_local too. Since they all are, we don't have to print
dso_local to the textual representation, making it a bit more compact
and easier to read.

llvm-svn: 322317

show more ...

ThinLTO: Don't import aliases of any kind (even linkonce_odr)

Summary:
Until a more advanced version of importing can be implemented for
aliases (one that imports an alias as an available_externally

ThinLTO: Don't import aliases of any kind (even linkonce_odr)

Summary:
Until a more advanced version of importing can be implemented for
aliases (one that imports an alias as an available_externally definition
of the aliasee), skip the narrow subset of cases that was possible but
came at a cost: aliases of linkonce_odr functions could be imported
because the linkonce_odr function could be safely duplicated from the
source module. This came/comes at the cost of not being able to 'home'
imported linkonce functions (they had to be emitted linkonce_odr in all
the destination modules (even if they weren't used by an alias) rather
than as available_externally - causing extra object size).

Tangentially, this also was the only reason ThinLTO would emit multiple
CUs in to the resulting DWARF - which happens to be a problem for
Fission (there's a fix for this in GDB but not released yet, etc).
(actually it's not the only reason - but I'm sending a patch to fix the
other reason shortly)

There's no reason to believe this particularly narrow alias importing
was especially/meaningfully important, only that it was /possible/ to
implement in this way. When a more general solution is done, it should
still satisfy the DWARF concerns above, since the import will still be
available_externally, and thus not create extra CUs.

Since now all aliases are treated the same, I removed/simplified some
test cases since they were testing corner cases where there are no
longer any corners.

Reviewers: tejohnson, mehdi_amini

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

llvm-svn: 309278

show more ...

[ThinLTO] Stop importing constant global vars as copies in the backend

Summary:
We were doing an optimization in the ThinLTO backends of importing
constant unnamed_addr globals unconditionally as a

[ThinLTO] Stop importing constant global vars as copies in the backend

Summary:
We were doing an optimization in the ThinLTO backends of importing
constant unnamed_addr globals unconditionally as a local copy (regardless
of whether the thin link decided to import them). This should be done in
the thin link instead, so that resulting exported references are marked
and promoted appropriately, but will need a summary enhancement to mark
these variables as constant unnamed_addr.

The function import logic during the thin link was trying to handle
this proactively, by conservatively marking all values referenced in
the initializer lists of exported global variables as also exported.
However, this only handled values referenced directly from the
initializer list of an exported global variable. If the value is itself
a constant unnamed_addr variable, we could end up exporting its
references as well. This caused multiple issues. The first is that the
transitively exported references weren't promoted. Secondly, some could
not be promoted/renamed (e.g. they had a section or other constraint).
recursively, instead of just adding the first level of initializer list
references to the ExportList directly.

Remove this optimization and the associated handling in the function
import backend. SPEC measurements indicate we weren't getting much
from it in any case.

Fixes PR31052.

Reviewers: mehdi_amini

Subscribers: krasin, llvm-commits

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

llvm-svn: 288446

show more ...

ThinLTO: never promote as external weak

This linkage is *not* intended to express that a declaration refers
to a weak symbol, but that the symbol might not be present at link
time. I don't believe i

ThinLTO: never promote as external weak

This linkage is *not* intended to express that a declaration refers
to a weak symbol, but that the symbol might not be present at link
time. I don't believe it was the intent.

From: Mehdi Amini <[email protected]>
llvm-svn: 266856

show more ...

Move summary creation out of llvm-as into opt

Summary:
Let keep llvm-as "dumb": it converts textual IR to bitcode. This
commit removes the dependency from llvm-as to libLLVMAnalysis.
We'll add back

Move summary creation out of llvm-as into opt

Summary:
Let keep llvm-as "dumb": it converts textual IR to bitcode. This
commit removes the dependency from llvm-as to libLLVMAnalysis.
We'll add back summary in llvm-as if we get to a textual
representation for it at some point. In the meantime, opt seems
like a better place for that.

Reviewers: tejohnson

Subscribers: joker.eph, llvm-commits

Differential Revision: http://reviews.llvm.org/D19032

From: Mehdi Amini <[email protected]>
llvm-svn: 266131

show more ...

ThinLTO renaming: use module hash instead of position in the summary

This is more robust to changes in the link ordering.

Differential Revision: http://reviews.llvm.org/D18946

From: Mehdi Amini <m

ThinLTO renaming: use module hash instead of position in the summary

This is more robust to changes in the link ordering.

Differential Revision: http://reviews.llvm.org/D18946

From: Mehdi Amini <[email protected]>
llvm-svn: 266018

show more ...

Rework linkInModule(), making it oblivious to ThinLTO

Summary:
ThinLTO is relying on linkInModule to import selected function.
However a lot of "magic" was hidden in linkInModule and the IRMover,
wh

Rework linkInModule(), making it oblivious to ThinLTO

Summary:
ThinLTO is relying on linkInModule to import selected function.
However a lot of "magic" was hidden in linkInModule and the IRMover,
who would rename and promote global variables on the fly.

This is moving to an approach where the steps are decoupled and the
client is reponsible to specify the list of globals to import.
As a consequence some test are changed because they were relying on
the previous behavior which was importing the definition of *every*
single global without control on the client side.
Now the burden is on the client to decide if a global has to be imported
or not.

Reviewers: tejohnson

Subscribers: joker.eph, llvm-commits

Differential Revision: http://reviews.llvm.org/D18122

From: Mehdi Amini <[email protected]>
llvm-svn: 263863

show more ...

[ThinLTO] Renaming of function index to module summary index (NFC)

(Resubmitting after fixing missing file issue)

With the changes in r263275, there are now more than just functions in
the summary.

[ThinLTO] Renaming of function index to module summary index (NFC)

(Resubmitting after fixing missing file issue)

With the changes in r263275, there are now more than just functions in
the summary. Completed the renaming of data structures (started in
r263275) to reflect the wider scope. In particular, changed the
FunctionIndex* data structures to ModuleIndex*, and renamed related
variables and comments. Also renamed the files to reflect the changes.

A companion clang patch will immediately succeed this patch to reflect
this renaming.

llvm-svn: 263513

show more ...

Revert "[ThinLTO] Renaming of function index to module summary index (NFC)"

This reverts commit r263490. Missed a file.

llvm-svn: 263493

[ThinLTO] Renaming of function index to module summary index (NFC)

With the changes in r263275, there are now more than just functions in
the summary. Completed the renaming of data structures (star

[ThinLTO] Renaming of function index to module summary index (NFC)

With the changes in r263275, there are now more than just functions in
the summary. Completed the renaming of data structures (started in
r263275) to reflect the wider scope. In particular, changed the
FunctionIndex* data structures to ModuleIndex*, and renamed related
variables and comments. Also renamed the files to reflect the changes.

A companion clang patch will immediately succeed this patch to reflect
this renaming.

llvm-svn: 263490

show more ...

Switch the linker to having a whitelist of GVs.

This replaces DoNotLinkFromSource with ValuesToLink. It also moves the
computation of ValuesToLink earlier.

It is a bit simpler and an important step

Switch the linker to having a whitelist of GVs.

This replaces DoNotLinkFromSource with ValuesToLink. It also moves the
computation of ValuesToLink earlier.

It is a bit simpler and an important step in slitting the linker into an
ir mover and a linker proper.

The test change is because we now avoid creating dead declarations.

llvm-svn: 254559

show more ...

Delete what is now duplicated code.

Having to import an alias as declaration is not thinlto specific.

The test difference are because when we already have a decl and we are
not importing it, we jus

Delete what is now duplicated code.

Having to import an alias as declaration is not thinlto specific.

The test difference are because when we already have a decl and we are
not importing it, we just leave the decl alone.

llvm-svn: 254556

show more ...

Disallow aliases to available_externally.

They are as much trouble as aliases to declarations. They are requiring
the code generator to define a symbol with the same value as another
symbol, but the

Disallow aliases to available_externally.

They are as much trouble as aliases to declarations. They are requiring
the code generator to define a symbol with the same value as another
symbol, but the second symbol is undefined.

If representing this is important for some optimization, we could add
support for available_externally aliases. They would be *required* to
point to a declaration (or available_externally definition).

llvm-svn: 254170

show more ...

[ThinLTO] Handle bitcode without function summary sections gracefully

Summary:
Several fixes to the handling of bitcode files without function summary
sections so that they are skipped during ThinLT

[ThinLTO] Handle bitcode without function summary sections gracefully

Summary:
Several fixes to the handling of bitcode files without function summary
sections so that they are skipped during ThinLTO processing in llvm-lto
and the gold plugin when appropriate instead of aborting.

1 Don't assert when trying to add a FunctionInfo that doesn't have
a summary attached.
2 Skip FunctionInfo structures that don't have attached function summary
sections when trying to create the combined function summary.
3 In both llvm-lto and gold-plugin, check whether a bitcode file has
a function summary section before trying to parse the index, and skip
the bitcode file if it does not.
4 Fix hasFunctionSummaryInMemBuffer in BitcodeReader, which had a bug
where we returned to early while looking for the summary section.

Also added llvm-lto and gold-plugin based tests for cases where we
don't have function summaries in the bitcode file. I verified that
either the first couple fixes described above are enough to avoid the
crashes, or fixes 1,3,4. But have combined them all here for added
robustness.

Reviewers: joker.eph

Subscribers: llvm-commits, joker.eph

Differential Revision: http://reviews.llvm.org/D14903

llvm-svn: 253796

show more ...

[ThinLTO] Update test to be more tolerant of ordering changes

Update the ThinLTO function importing test to use DAG forms of checks so
that it is more tolerant of changes to relative ordering betwee

[ThinLTO] Update test to be more tolerant of ordering changes

Update the ThinLTO function importing test to use DAG forms of checks so
that it is more tolerant of changes to relative ordering between
imported decls/defs. This reduces the number of changes required by the
comdat importing patch I am sending for review shortly.

llvm-svn: 252932

show more ...

[ThinLTO] WeakAny fixes/cleanup

Ensure WeakAny variables are imported as ExternalWeak declarations. To
handle WeakAny more consistently and fix this issue:

1) Update helper doImportAsDefinition to

[ThinLTO] WeakAny fixes/cleanup

Ensure WeakAny variables are imported as ExternalWeak declarations. To
handle WeakAny more consistently and fix this issue:

1) Update helper doImportAsDefinition to properly flag WeakAny variables
and aliases as not importing defintions.

Update callers of doImportAsDefinition to remove now redundant checks for
WeakAny aliases, or ignore aliases, as appropriate.

2) Add any !doImportAsDefinition GVs to DoNotLinkFromSource set during
linking of the GV prototype, where we usually add GVs to the
DoNotLinkFromSource set for other reasons.

Remove now unnecessary adding of WeakAny aliases to
DoNotLinkFromSource set from copyGlobalAliasProto.

Remove now unnecessary guard against linking non-imported function
bodies from ModuleLinker::run.

llvm-svn: 252626

show more ...

[ThinLTO] Always set linkage type to external when converting alias

When converting an alias to a non-alias when the aliasee is not
imported, ensure that the linkage type is set to external so that

[ThinLTO] Always set linkage type to external when converting alias

When converting an alias to a non-alias when the aliasee is not
imported, ensure that the linkage type is set to external so that it is
a valid linkage type. Added a test case that exposed this issue.

llvm-svn: 252054

show more ...

Restore "Support for ThinLTO function importing and symbol linking."

This restores commit r251837, with the new library dependence added to
llvm-link/Makefile to address bot failures.

llvm-svn: 251

Restore "Support for ThinLTO function importing and symbol linking."

This restores commit r251837, with the new library dependence added to
llvm-link/Makefile to address bot failures.

llvm-svn: 251866

show more ...

Support for ThinLTO function importing and symbol linking.

Summary:
Support for necessary linkage changes and symbol renaming during
ThinLTO function importing.

Also includes llvm-link support for

Support for ThinLTO function importing and symbol linking.

Summary:
Support for necessary linkage changes and symbol renaming during
ThinLTO function importing.

Also includes llvm-link support for manually importing functions
and associated llvm-link based tests.

Note that this does not include support for intelligently importing
metadata, which is currently imported duplicate times. That support will
be in the follow-on patch, and currently is ignored by the tests.

Reviewers: dexonsmith, joker.eph, davidxl

Subscribers: tobiasvk, tejohnson, llvm-commits

Differential Revision: http://reviews.llvm.org/D13515

llvm-svn: 251837

show more ...