Commit Graph

1251 Commits

Author SHA1 Message Date
Robin Morisset
217b38e19a Fix typos in comments, NFC
Summary: Just fixing comments, no functional change.

Test Plan: N/A

Reviewers: jfb

Subscribers: mcrosier, llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216784 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-29 21:53:01 +00:00
Rafael Espindola
2292996e1a Pass a MemoryBufferRef when we can avoid taking ownership.
The attached patch simplifies a few interfaces that don't need to take
ownership of a buffer.

For example, both parseAssembly and parseBitcodeFile will parse the
entire buffer before returning. There is no need to take ownership.

Using a MemoryBufferRef makes it obvious in the type signature that
there is no ownership transfer.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216488 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-26 21:49:01 +00:00
Reid Kleckner
44b3a0b411 Declare that musttail calls in variadic functions forward the ellipsis
Summary:
There is no functionality change here except in the way we assemble and
dump musttail calls in variadic functions. There's really no need to
separate out the bits for musttail and "is forwarding varargs" on call
instructions. A musttail call by definition has to forward the ellipsis
or it would fail verification.

Reviewers: chandlerc, nlewycky

Subscribers: llvm-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216423 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-26 00:33:28 +00:00
David Blaikie
95ca0fb247 Explicitly pass ownership of the MemoryBuffer to AddNewSourceBuffer using std::unique_ptr
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216223 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-21 20:44:56 +00:00
Rafael Espindola
b12ab608fe Split parseAssembly into parseAssembly and parseAssemblyInto.
This should restore the functionality of parsing new code into an existing
module without the confusing interface.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216031 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 22:05:47 +00:00
Duncan P. N. Exon Smith
7838818ad7 IR: Implement uselistorder assembly directives
Implement `uselistorder` and `uselistorder_bb` assembly directives,
which allow the use-list order to be recovered when round-tripping to
assembly.

This is the bulk of PR20515.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@216025 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 21:30:15 +00:00
Rafael Espindola
9b29ff99c0 Modernize the .ll parsing interface.
* Use StringRef instead of std::string&
* Return a std::unique_ptr<Module> instead of taking an optional module to write
  to (was not really used).
* Use current comment style.
* Use current naming convention.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215989 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 16:58:54 +00:00
Duncan P. N. Exon Smith
165897841b LLParser: Handle BlockAddresses on-the-fly
Previously all `blockaddress()` constants were treated as forward
references.  They were resolved twice:  once at the end of the function
in question, and again at the end of the module.  Furthermore, if the
same blockaddress was referenced N times, the parser created N distinct
`GlobalVariable`s (one for each reference).

Instead, resolve all block addresses at the beginning of the function,
creating the standard `BasicBlock` forward references used for all other
basic block references.  After the function, all references can be
resolved immediately.  To check for the condition of parsing block
addresses from within the same function, I created a reference to the
current per-function-state in `BlockAddressPFS`.

Also, create only one forward-reference per basic block.  Because
forward references to block addresses are rare, the data structure here
shouldn't matter.  If somehow it does someday, this can be pretty easily
changed to a `DenseMap<std::pair<ValID, ValID>, GV>`.

This is part of PR20515.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215952 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-19 00:13:19 +00:00
Rafael Espindola
0282239051 These classes only need a StringRef, not a MemoryBuffer.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215945 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-18 22:28:28 +00:00
Rafael Espindola
285133714f Delete unused method.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215944 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-18 22:20:18 +00:00
Rafael Espindola
822199b9e6 Pass a std::uinque_ptr to ParseAssembly to make the ownership explicit. NFC.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215852 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-17 21:36:47 +00:00
Benjamin Kramer
00e08fcaa0 Canonicalize header guards into a common format.
Add header guards to files that were missing guards. Remove #endif comments
as they don't seem common in LLVM (we can easily add them back if we decide
they're useful)

Changes made by clang-tidy with minor tweaks.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@215558 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-13 16:26:38 +00:00
Duncan P. N. Exon Smith
b72118fb52 Remove dead code in condition
Whether or not it's appropriate, labels have been first-class types
since r51511.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214908 91177308-0d34-0410-b5e6-96231b3b80d8
2014-08-05 18:22:58 +00:00
Rafael Espindola
d57120551f Use "weak alias" instead of "alias weak"
Before this patch we had

@a = weak global ...
but
@b = alias weak ...

The patch changes aliases to look more like global variables.

Looking at some really old code suggests that the reason was that the old
bison based parser had a reduction for alias linkages and another one for
global variable linkages. Putting the alias first avoided the reduce/reduce
conflict.

The days of the old .ll parser are long gone. The new one parses just "linkage"
and a later check is responsible for deciding if a linkage is valid in a
given context.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@214355 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-30 22:51:54 +00:00
Saleem Abdulrasool
e2c63ff3c9 AsmParser: remove deprecated LLIR support
linker_private and linker_private_weak were deprecated in 3.5.  Remove support
for them now that the 3.5 branch has been created.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213777 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-23 18:09:31 +00:00
Hal Finkel
11af4b49b2 Add a dereferenceable attribute
This attribute indicates that the parameter or return pointer is
dereferenceable. Practically speaking, loads from such a pointer within the
associated byte range are safe to speculatively execute. Such pointer
parameters are common in source languages (C++ references, for example).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213385 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-18 15:51:28 +00:00
Rafael Espindola
7cba2a973f Update the MemoryBuffer API to use ErrorOr.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212405 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-06 17:43:13 +00:00
David Majnemer
c8a1169c93 IR: Add COMDATs to the IR
This new IR facility allows us to represent the object-file semantic of
a COMDAT group.

COMDATs allow us to tie together sections and make the inclusion of one
dependent on another. This is required to implement features like MS
ABI VFTables and optimizing away certain kinds of initialization in C++.

This functionality is only representable in COFF and ELF, Mach-O has no
similar mechanism.

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211920 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-27 18:19:56 +00:00
Alp Toker
d0996e5b33 ParseIR: don't take ownership of the MemoryBuffer
clang was needlessly duplicating whole memory buffer contents in an attempt to
satisfy unclear ownership semantics. Let's just hide internal LLVM quirks and
present a simple non-owning interface.

The public C API preserves previous behaviour for stability.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211861 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-27 04:33:58 +00:00
Alp Toker
8dd8d5c2b2 Revert "Introduce a string_ostream string builder facilty"
Temporarily back out commits r211749, r211752 and r211754.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211814 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-26 22:52:05 +00:00
Alp Toker
2559070422 Introduce a string_ostream string builder facilty
string_ostream is a safe and efficient string builder that combines opaque
stack storage with a built-in ostream interface.

small_string_ostream<bytes> additionally permits an explicit stack storage size
other than the default 128 bytes to be provided. Beyond that, storage is
transferred to the heap.

This convenient class can be used in most places an
std::string+raw_string_ostream pair or SmallString<>+raw_svector_ostream pair
would previously have been used, in order to guarantee consistent access
without byte truncation.

The patch also converts much of LLVM to use the new facility. These changes
include several probable bug fixes for truncated output, a programming error
that's no longer possible with the new interface.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211749 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-26 00:00:48 +00:00
Eli Bendersky
bb167336b3 Rename loop unrolling and loop vectorizer metadata to have a common prefix.
[LLVM part]

These patches rename the loop unrolling and loop vectorizer metadata
such that they have a common 'llvm.loop.' prefix.  Metadata name
changes:

llvm.vectorizer.* => llvm.loop.vectorizer.*
llvm.loopunroll.* => llvm.loop.unroll.*

This was a suggestion from an earlier review
(http://reviews.llvm.org/D4090) which added the loop unrolling
metadata. 

Patch by Mark Heffernan.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@211710 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-25 15:41:00 +00:00
Tim Northover
8f2a85e099 IR: add "cmpxchg weak" variant to support permitted failure.
This commit adds a weak variant of the cmpxchg operation, as described
in C++11. A cmpxchg instruction with this modifier is permitted to
fail to store, even if the comparison indicated it should.

As a result, cmpxchg instructions must return a flag indicating
success in addition to their original iN value loaded. Thus, for
uniformity *all* cmpxchg instructions now return "{ iN, i1 }". The
second flag is 1 when the store succeeded.

At the DAG level, a new ATOMIC_CMP_SWAP_WITH_SUCCESS node has been
added as the natural representation for the new cmpxchg instructions.
It is a strong cmpxchg.

By default this gets Expanded to the existing ATOMIC_CMP_SWAP during
Legalization, so existing backends should see no change in behaviour.
If they wish to deal with the enhanced node instead, they can call
setOperationAction on it. Beware: as a node with 2 results, it cannot
be selected from TableGen.

Currently, no use is made of the extra information provided in this
patch. Test updates are almost entirely adapting the input IR to the
new scheme.

Summary for out of tree users:
------------------------------

+ Legacy Bitcode files are upgraded during read.
+ Legacy assembly IR files will be invalid.
+ Front-ends must adapt to different type for "cmpxchg".
+ Backends should be unaffected by default.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210903 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-13 14:24:07 +00:00
Rafael Espindola
4e2b922131 Remove 'using std::errro_code' from lib.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210871 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-13 02:24:39 +00:00
Rafael Espindola
5c792faa0e Don't use 'using std::error_code' in include/llvm.
This should make sure that most new uses use the std prefix.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210835 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-12 21:46:39 +00:00
Rafael Espindola
d5132f9073 Remove system_error.h.
This is a minimal change to remove the header. I will remove the occurrences
of "using std::error_code" in a followup patch.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210803 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-12 17:38:55 +00:00
Rafael Espindola
6fd1b8ee48 Allow aliases to be unnamed_addr.
Alias with unnamed_addr were in a strange state. It is stored in GlobalValue,
the language reference talks about "unnamed_addr aliases" but the verifier
was rejecting them.

It seems natural to allow unnamed_addr in aliases:

* It is a property of how it is accessed, not of the data itself.
* It is perfectly possible to write code that depends on the address
of an alias.

This patch then makes unname_addr legal for aliases. One side effect is that
the syntax changes for a corner case: In globals, unnamed_addr is now printed
before the address space.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210302 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-06 01:20:28 +00:00
Tom Roeder
5d0f7af3dc Add a new attribute called 'jumptable' that creates jump-instruction tables for functions marked with this attribute.
It includes a pass that rewrites all indirect calls to jumptable functions to pass through these tables.

This also adds backend support for generating the jump-instruction tables on ARM and X86.
Note that since the jumptable attribute creates a second function pointer for a
function, any function marked with jumptable must also be marked with unnamed_addr.


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210280 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-05 19:29:43 +00:00
Rafael Espindola
dcac1523c0 Clauses in a landingpad are always Constant. Use a stricter type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210203 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-04 18:51:31 +00:00
Rafael Espindola
f35a459723 Update comments to match reality.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210125 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-03 20:25:26 +00:00
Rafael Espindola
8c2d2770e2 Fix a small bug in the parsing of anonymous globals.
It was able to parse

hidden dllexport global i32 42

but not

dllexport global i32 42

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210121 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-03 20:07:32 +00:00
Rafael Espindola
85422f7da3 Simplify the parsing of unnamed globals. No functionality changed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210120 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-03 20:00:20 +00:00
Rafael Espindola
b20541c5fb Update comment. This should have been part of r210062.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210119 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-03 19:38:37 +00:00
Rafael Espindola
2d21b25393 Allow alias to point to an arbitrary ConstantExpr.
This  patch changes GlobalAlias to point to an arbitrary ConstantExpr and it is
up to MC (or the system assembler) to decide if that expression is valid or not.

This reduces our ability to diagnose invalid uses and how early we can spot
them, but it also lets us do things like

@test5 = alias inttoptr(i32 sub (i32 ptrtoint (i32* @test2 to i32),
                                 i32 ptrtoint (i32* @bar to i32)) to i32*)

An important implication of this patch is that the notion of aliased global
doesn't exist any more. The alias has to encode the information needed to
access it in its metadata (linkage, visibility, type, etc).

Another consequence to notice is that getSection has to return a "const char *".
It could return a NullTerminatedStringRef if there was such a thing, but when
that was proposed the decision was to just uses "const char*" for that.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210062 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-03 02:41:57 +00:00
Rafael Espindola
665d42accf [pr19844] Add thread local mode to aliases.
This matches gcc's behavior. It also seems natural given that aliases
contain other properties that govern how it is accessed (linkage,
visibility, dll storage).

Clang still has to be updated to expose this feature to C.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209759 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-28 18:15:43 +00:00
Richard Smith
651f680b79 [modules] Add module maps for LLVM. These are not quite ready for prime-time
yet, but only a few more Clang patches need to land. (I have 'ninja check'
passing locally.)


git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209269 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-21 02:46:14 +00:00
Nick Lewycky
fe47ebfad3 Add 'nonnull', a new parameter and return attribute which indicates that the pointer is not null. Instcombine will elide comparisons between these and null. Patch by Luqman Aden!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209185 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-20 01:23:40 +00:00
Rafael Espindola
c86235f4eb Use create methods since msvc doesn't handle delegating constructors.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209076 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-17 21:29:57 +00:00
Rafael Espindola
fbd8cc0926 Reduce abuse of default values in the GlobalAlias constructor.
This is in preparation for adding an optional offset.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209073 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-17 19:57:46 +00:00
Rafael Espindola
27c076ae40 Fix most of PR10367.
This patch changes the design of GlobalAlias so that it doesn't take a
ConstantExpr anymore. It now points directly to a GlobalObject, but its type is
independent of the aliasee type.

To avoid changing all alias related tests in this patches, I kept the common
syntax

@foo = alias i32* @bar

to mean the same as now. The cases that used to use cast now use the more
general syntax

@foo = alias i16, i32* @bar.

Note that GlobalAlias now behaves a bit more like GlobalVariable. We
know that its type is always a pointer, so we omit the '*'.

For the bitcode, a nice surprise is that we were writing both identical types
already, so the format change is minimal. Auto upgrade is handled by looking
through the casts and no new fields are needed for now. New bitcode will
simply have different types for Alias and Aliasee.

One last interesting point in the patch is that replaceAllUsesWith becomes
smart enough to avoid putting a ConstantExpr in the aliasee. This seems better
than checking and updating every caller.

A followup patch will delete getAliasedGlobal now that it is redundant. Another
patch will add support for an explicit offset.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209007 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-16 19:35:39 +00:00
Rafael Espindola
ab67b30df6 Change the GlobalAlias constructor to look a bit more like GlobalVariable.
This is part of the fix for pr10367. A GlobalAlias always has a pointer type,
so just have the constructor build the type.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208983 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-16 13:34:04 +00:00
Reid Kleckner
d30c11edde Revert "[ms-cxxabi] Add a new calling convention that swaps 'this' and 'sret'"
This reverts commit r200561.

This calling convention was an attempt to match the MSVC C++ ABI for
methods that return structures by value.  This solution didn't scale,
because it would have required splitting every CC available on Windows
into two: one for methods and one for free functions.

Now that we can put sret on the second arg (r208453), and Clang does
that (r208458), revert this hack.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208459 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-09 22:56:42 +00:00
Rafael Espindola
1acea2db56 Don't crash on redefinitions.
One error we were not deleting the alias or putting it in the Module. The
end result is that there was an use left of the aliasee when the module was
deleted.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208447 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-09 21:49:17 +00:00
Duncan P. N. Exon Smith
76c17d324c IR: Don't allow non-default visibility on local linkage
Visibilities of `hidden` and `protected` are meaningless for symbols
with local linkage.

  - Change the assembler to reject non-default visibility on symbols
    with local linkage.

  - Change the bitcode reader to auto-upgrade `hidden` and `protected`
    to `default` when the linkage is local.

  - Update LangRef.

<rdar://problem/16141113>

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208263 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-07 22:57:20 +00:00
Reid Kleckner
710c1a449d Add 'musttail' marker to call instructions
This is similar to the 'tail' marker, except that it guarantees that
tail call optimization will occur.  It also comes with convervative IR
verification rules that ensure that tail call optimization is possible.

Reviewers: nicholas

Differential Revision: http://llvm-reviews.chandlerc.com/D3240

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207143 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-24 20:14:34 +00:00
Craig Topper
695aa80f07 [C++11] More 'nullptr' conversion. In some cases just using a boolean check instead of comparing to nullptr.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206356 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-16 04:21:27 +00:00
Craig Topper
0b6cb7104b [C++11] More 'nullptr' conversion. In some cases just using a boolean check instead of comparing to nullptr.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206252 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-15 06:32:26 +00:00
Saleem Abdulrasool
fa254cb46c AsmParser: add a warning for compatibility parsing
This adds a warning when linker_private or linker_private_weak is provided and
we handle it in a compatible manner.

Suggested by Chris Lattner!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205681 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-05 22:42:53 +00:00
Saleem Abdulrasool
48ee81c679 AsmParser: restore LLVM IR compatibility for linker_private{,_weak}
This restores the linker_private and linker_private_weak lexemes to permit
translation of the deprecated lexmes.  The behaviour is identical to the bitcode
handling: linker_private and linker_private_weak are handled as if private had
been specified.  This enables compatibility with IR generated by LLVM 3.4.

Reported on IRC by ki9a!

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@205675 91177308-0d34-0410-b5e6-96231b3b80d8
2014-04-05 20:51:58 +00:00
Rafael Espindola
1f21e0dd0d Remove the linker_private and linker_private_weak linkages.
These linkages were introduced some time ago, but it was never very
clear what exactly their semantics were or what they should be used
for. Some investigation found these uses:

* utf-16 strings in clang.
* non-unnamed_addr strings produced by the sanitizers.

It turns out they were just working around a more fundamental problem.
For some sections a MachO linker needs a symbol in order to split the
section into atoms, and llvm had no idea that was the case. I fixed
that in r201700 and it is now safe to use the private linkage. When
the object ends up in a section that requires symbols, llvm will use a
'l' prefix instead of a 'L' prefix and things just work.

With that, these linkages were already dead, but there was a potential
future user in the objc metadata information. I am still looking at
CGObjcMac.cpp, but at this point I am convinced that linker_private
and linker_private_weak are not what they need.

The objc uses are currently split in

* Regular symbols (no '\01' prefix). LLVM already directly provides
whatever semantics they need.
* Uses of a private name (start with "\01L" or "\01l") and private
linkage. We can drop the "\01L" and "\01l" prefixes as soon as llvm
agrees with clang on L being ok or not for a given section. I have two
patches in code review for this.
* Uses of private name and weak linkage.

The last case is the one that one could think would fit one of these
linkages. That is not the case. The semantics are

* the linker will merge these symbol by *name*.
* the linker will hide them in the final DSO.

Given that the merging is done by name, any of the private (or
internal) linkages would be a bad match. They allow llvm to rename the
symbols, and that is really not what we want. From the llvm point of
view, these objects should really be (linkonce|weak)(_odr)?.

For now, just keeping the "\01l" prefix is probably the best for these
symbols. If we one day want to have a more direct support in llvm,
IMHO what we should add is not a linkage, it is just a hidden_symbol
attribute. It would be applicable to multiple linkages. For example,
on weak it would produce the current behavior we have for objc
metadata. On internal, it would be equivalent to private (and we
should then remove private).

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203866 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-13 23:18:37 +00:00