[IR] Change representation of getelementptr inrange (#84341)

As part of the migration to ptradd
(https://discourse.llvm.org/t/rfc-replacing-getelementptr-with-ptradd/68699),
we need to change the

[IR] Change representation of getelementptr inrange (#84341)

As part of the migration to ptradd
(https://discourse.llvm.org/t/rfc-replacing-getelementptr-with-ptradd/68699),
we need to change the representation of the `inrange` attribute, which
is used for vtable splitting.

Currently, inrange is specified as follows:

```
getelementptr inbounds ({ [4 x ptr], [4 x ptr] }, ptr @vt, i64 0, inrange i32 1, i64 2)
```

The `inrange` is placed on a GEP index, and all accesses must be "in
range" of that index. The new representation is as follows:

```
getelementptr inbounds inrange(-16, 16) ({ [4 x ptr], [4 x ptr] }, ptr @vt, i64 0, i32 1, i64 2)
```

This specifies which offsets are "in range" of the GEP result. The new
representation will continue working when canonicalizing to ptradd
representation:

```
getelementptr inbounds inrange(-16, 16) (i8, ptr @vt, i64 48)
```

The inrange offsets are relative to the return value of the GEP. An
alternative design could make them relative to the source pointer
instead. The result-relative format was chosen on the off-chance that we
want to extend support to non-constant GEPs in the future, in which case
this variant is more expressive.

This implementation "upgrades" the old inrange representation in bitcode
by simply dropping it. This is a very niche feature, and I don't think
trying to upgrade it is worthwhile. Let me know if you disagree.

show more ...

[clang codegen][regression] Add dso_local/hidden/etc. markings to VTT definitions and declarations (#72452)

https://reviews.llvm.org/D128482 regressed certain cases of VTT emission
which are no lon

[clang codegen][regression] Add dso_local/hidden/etc. markings to VTT definitions and declarations (#72452)

https://reviews.llvm.org/D128482 regressed certain cases of VTT emission
which are no longer hidden with -fvisibility=hidden.

Fix this regression by marking both declarations and definitions.

Fixes [clang codegen][regression] VTT definitions missing
dso_local/hidden/etc markings #72451

show more ...

[test] Test #pragma GCC visibility interaction with explicit instantiations

[clang] Remove rdar links; NFC

We have a new policy in place making links to private resources
something we try to avoid in source and test files. Normally, we'd
organically switch to the new policy

[clang] Remove rdar links; NFC

We have a new policy in place making links to private resources
something we try to avoid in source and test files. Normally, we'd
organically switch to the new policy rather than make a sweeping change
across a project. However, Clang is in a somewhat special circumstance
currently: recently, I've had several new contributors run into rdar
links around test code which their patch was changing the behavior of.
This turns out to be a surprisingly bad experience, especially for
newer folks, for a handful of reasons: not understanding what the link
is and feeling intimidated by it, wondering whether their changes are
actually breaking something important to a downstream in some way,
having to hunt down strangers not involved with the patch to impose on
them for help, accidental pressure from asking for potentially private
IP to be made public, etc. Because folks run into these links entirely
by chance (through fixing bugs or working on new features), there's not
really a set of problematic links to focus on -- all of the links have
basically the same potential for causing these problems. As a result,
this is an omnibus patch to remove all such links.

This was not a mechanical change; it was done by manually searching for
rdar, radar, radr, and other variants to find all the various
problematic links. From there, I tried to retain or reword the
surrounding comments so that we would lose as little context as
possible. However, because most links were just a plain link with no
supporting context, the majority of the changes are simple removals.

Differential Review: https://reviews.llvm.org/D158071

show more ...

[test] Improve visibility.cpp

Revert "Remove rdar links; NFC"

This reverts commit d618f1c3b12effd0c2bdb7d02108d3551f389d3d.
This commit wasn't reviewed ahead of time and significant concerns were
raised immediately after it land

Revert "Remove rdar links; NFC"

This reverts commit d618f1c3b12effd0c2bdb7d02108d3551f389d3d.
This commit wasn't reviewed ahead of time and significant concerns were
raised immediately after it landed. According to our developer policy
this warrants immediate revert of the commit.

https://llvm.org/docs/DeveloperPolicy.html#patch-reversion-policy

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

show more ...

[test] Add more instantiation cases to visibility.cpp

Remove rdar links; NFC

This removes links to rdar, which is an internal bug tracker that the
community doesn't have visibility into.

See further discussion at:
https://discourse.llvm.org/t/code-rev

Remove rdar links; NFC

This removes links to rdar, which is an internal bug tracker that the
community doesn't have visibility into.

See further discussion at:
https://discourse.llvm.org/t/code-review-reminder-about-links-in-code-commit-messages/71847

show more ...

[test] Improve symbol visibility test

[test] Change cc1 -fvisibility to -fvisibility=

[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 ...