[clang codegen] Add dso_local/hidden/etc. markings to VTT declarations

We were marking definitions, but not declarations. Marking declarations
makes computing the address more efficient.

Fixes issu

[clang codegen] Add dso_local/hidden/etc. markings to VTT declarations

We were marking definitions, but not declarations. Marking declarations
makes computing the address more efficient.

Fixes issue reported at https://discourse.llvm.org/t/63090

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

show more ...

Revert "[CodeGenModule] Set dso_local for Mach-O GlobalValue"

This reverts commit 809a1e0ffd7af40ee27270ff8ba2ffc927330e71.

Mach-O doesn't support dso_local and this change broke XNU because of the

Revert "[CodeGenModule] Set dso_local for Mach-O GlobalValue"

This reverts commit 809a1e0ffd7af40ee27270ff8ba2ffc927330e71.

Mach-O doesn't support dso_local and this change broke XNU because of the use of dso_local.

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

show more ...

[CodeGenModule] Set dso_local for Mach-O GlobalValue

* static relocation model: always
* other relocation models: if isStrongDefinitionForLinker

This will make LLVM IR emitted for COFF/Mach-O and e

[CodeGenModule] Set dso_local for Mach-O GlobalValue

* static relocation model: always
* other relocation models: if isStrongDefinitionForLinker

This will make LLVM IR emitted for COFF/Mach-O and executable ELF similar.

show more ...

[Driver] Alias -fvisibility=internal to -fvisibility=hidden

The ELF symbol visibilities are:
- internal: Not visibile across DSOs, cannot pass address across DSOs
- hidden: Not visibile across DSOs,

[Driver] Alias -fvisibility=internal to -fvisibility=hidden

The ELF symbol visibilities are:
- internal: Not visibile across DSOs, cannot pass address across DSOs
- hidden: Not visibile across DSOs, can be called indirectly
- default: Usually visible across DSOs, possibly interposable
- protected: Visible across DSOs, not interposable

LLVM only supports the latter 3 visibilities. Internal visibility is in
theory useful, as it allows you to assume that the caller is maintaining
a PIC register for you in %ebx, or in some other pre-arranged location.
As far as LLVM is concerned, this isn't worth the trouble. Using hidden
visibility is always correct, so we can just do that.

Resolves PR9183.

llvm-svn: 250954

show more ...

Itanium ABI: Mangle <mangled-name> according to the ABI

We attempted to be compatible with GCC's buggy mangling for templates
with a declaration for a template argument.

However, we weren't complet

Itanium ABI: Mangle <mangled-name> according to the ABI

We attempted to be compatible with GCC's buggy mangling for templates
with a declaration for a template argument.

However, we weren't completely successful in copying their bug in cases
like:
char foo;
template <char &C> decltype(C) f() { return foo; };
template char &f<foo>();

Instead, just follow the ABI specification. This fixes PR22621.

llvm-svn: 229644

show more ...

Emit DeferredDeclsToEmit in a DFS order.

Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that.

The advantages of the change are that

* The output order is a bit closer t

Emit DeferredDeclsToEmit in a DFS order.

Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that.

The advantages of the change are that

* The output order is a bit closer to the source order. The change to
test/CodeGenCXX/pod-member-memcpys.cpp is a good example.

* If we decide to deffer more, it will not cause as large changes in the
estcases as it would without this patch.

llvm-svn: 226751

show more ...

Fix pr18174.

Clang outputs LLVM one top level decl at a time. This combined with the
visibility computation code looking for the newest NamespaceDecl would cause
it to produce different results for

Fix pr18174.

Clang outputs LLVM one top level decl at a time. This combined with the
visibility computation code looking for the newest NamespaceDecl would cause
it to produce different results for nested namespaces.

The two options for producing consistent results are
* Delay codegen of anything inside a namespace until the end of the file.
* Don't look for the newest NamespaceDecl.

This patch implements the second option.
This matches the gcc behavior too.

llvm-svn: 196712

show more ...

CHECK-LABEL-ify some code gen tests to improve diagnostic experience when tests fail.

llvm-svn: 188447

Compute the visibility of static local variables consistently. Fixes PR16208.

llvm-svn: 184137

Don't cache the visibility of types.

Since r175326 an implicitly hidden template argument can cause a template
installation to become hidden, even if the template itself has an explicit
default visi

Don't cache the visibility of types.

Since r175326 an implicitly hidden template argument can cause a template
installation to become hidden, even if the template itself has an explicit
default visibility. This requires that we keep track of "late" additions
of the visibility attribute.

This is hopefully the last followup change. It just removes the caching of
visibilities from types so that we can see new attributes even after a type has
been used.

llvm-svn: 176164

show more ...

Use existing macros to simplify the test a bit.

llvm-svn: 176138

Use the most recent decl in getExplicitVisibility.

Now that implicitly hidden template arguments can make an instantiation hidden,
it is important to look at more than just the canonical decl of the

Use the most recent decl in getExplicitVisibility.

Now that implicitly hidden template arguments can make an instantiation hidden,
it is important to look at more than just the canonical decl of the argument
in order to see if an attribute is available in a more recent decl.

This has the disadvantage of exposing when getExplicitVisibility is called,
but lets us handle cases like

template <typename T>
struct __attribute__((visibility("default"))) barT {
static void zed() {}
};
class foo;
class __attribute__((visibility("default"))) foo;
template struct barT<foo>;

llvm-svn: 176112

show more ...

Ignore visibility from enclosing template arguments
for explicit member specializations.

llvm-svn: 175827

Add a new 'type_visibility' attribute to allow users to
control the visibility of a type for the purposes of RTTI
and template argument restrictions independently of how
visibility propagates to its

Add a new 'type_visibility' attribute to allow users to
control the visibility of a type for the purposes of RTTI
and template argument restrictions independently of how
visibility propagates to its non-type member declarations.

Also fix r175326 to not ignore template argument visibility
on a template explicit instantiation when a member has
an explicit attribute but the instantiation does not.

The type_visibility work is rdar://11880378

llvm-svn: 175587

show more ...

Rework the visibility computation algorithm in preparation
for distinguishing type vs. value visibility.

The changes to the visibility of explicit specializations
are intentional. The change to the

Rework the visibility computation algorithm in preparation
for distinguishing type vs. value visibility.

The changes to the visibility of explicit specializations
are intentional. The change to the "ugly" test case is
a consequence of a sensible implementation, and I am happy
to argue that this is better behavior. Other changes may
or may not be intended; it is quite difficult to divine
intent from some of the code I altered.

I've left behind a comment which I hope explains the
philosophy behind visibility computation.

llvm-svn: 175326

show more ...

Disable caching of visibility.

The testcase in pr14929 shows that this is extremely hard to do. If we choose
to apply the attribute, that causes the visibility of some decls to change and
that can h

Disable caching of visibility.

The testcase in pr14929 shows that this is extremely hard to do. If we choose
to apply the attribute, that causes the visibility of some decls to change and
that can happen really late (during codegen).

Current gcc warns and ignores the attribute in this testcase with a warning.
This suggest that the correct solution is to find a point in the compilation
where we can compute the visibility and
* assert it was never computed before
* reject any attempts to compute it again in the future (with warnings).

llvm-svn: 172305

show more ...

Consider the visibility of template template arguments. GCC doesn't, but it also
fails to consider the linkage, which we were already considering.

llvm-svn: 161070

Add a missing testcase for merging the visibility of two declarations used
as arguments of a template.

llvm-svn: 160911

Record visibility pragmas when we see a tag declaration. We might use it
to build a type before seeing the definition.

llvm-svn: 160339

Apply visibility pragmas to class template declarations. This is needed because
we might use the declaration to build a type before seeing the definition.

llvm-svn: 160176

Fix a bug in my previous commit. The problem is not that we were not using the
canonical decl for the template, but that we were not merging attributes for
templates at all!

llvm-svn: 160157

Use the canonical template decl when trying to find if it has a visibility
attribute.

llvm-svn: 160139

Process #pragma visibility early in the parsing of class definitions. Fixes
pr13338.

llvm-svn: 160105

Handle #pragma visibility in explicit specializations and enums.

llvm-svn: 160057

Don't process #pragma visibility during instantiation. The visibility of the
instantiation depends on the template, its arguments and parameters, but not
where it is instantiated.

llvm-svn: 160034