Commit Graph

15 Commits

Author SHA1 Message Date
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
Stephan Tolksdorf
ac01874f19 Test commit - remove trailing whitespace
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203834 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-13 19:07:39 +00:00
Reid Kleckner
65c98b9da4 [ms-cxxabi] Add a new calling convention that swaps 'this' and 'sret'
MSVC always places the 'this' parameter for a method first.  The
implicit 'sret' pointer for methods always comes second.  We already
implement this for __thiscall by putting sret parameters on the stack,
but __cdecl methods require putting both parameters on the stack in
opposite order.

Using a special calling convention allows frontends to keep the sret
parameter first, which avoids breaking lots of assumptions in LLVM and
Clang.

Fixes PR15768 with the corresponding change in Clang.

Reviewers: ributzka, majnemer

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200561 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-31 17:41:22 +00:00
Juergen Ributzka
ceaf829339 Add two new calling conventions for runtime calls
This patch adds two new target-independent calling conventions for runtime
calls - PreserveMost and PreserveAll.
The target-specific implementation for X86-64 is defined as following:
  - Arguments are passed as for the default C calling convention
  - The same applies for the return value(s)
  - PreserveMost preserves all GPRs - except R11
  - PreserveAll preserves all GPRs and all XMMs/YMMs - except R11

Reviewed by Lang and Philip

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199508 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-17 19:47:03 +00:00
Nico Rieck
38f68c5a2e Decouple dllexport/dllimport from linkage
Representing dllexport/dllimport as distinct linkage types prevents using
these attributes on templates and inline functions.

Instead of introducing further mixed linkage types to include linkonce and
weak ODR, the old import/export linkage types are replaced with a new
separate visibility-like specifier:

  define available_externally dllimport void @f() {}
  @Var = dllexport global i32 1, align 4

Linkage for dllexported globals and functions is now equal to their linkage
without dllexport. Imported globals and functions must be either
declarations with external linkage, or definitions with
AvailableExternallyLinkage.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199218 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-14 15:22:47 +00:00
Nico Rieck
55463f4ec1 Revert "Decouple dllexport/dllimport from linkage"
Revert this for now until I fix an issue in Clang with it.

This reverts commit r199204.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199207 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-14 12:38:32 +00:00
Nico Rieck
bce07a0c3b Decouple dllexport/dllimport from linkage
Representing dllexport/dllimport as distinct linkage types prevents using
these attributes on templates and inline functions.

Instead of introducing further mixed linkage types to include linkonce and
weak ODR, the old import/export linkage types are replaced with a new
separate visibility-like specifier:

  define available_externally dllimport void @f() {}
  @Var = dllexport global i32 1, align 4

Linkage for dllexported globals and functions is now equal to their linkage
without dllexport. Imported globals and functions must be either
declarations with external linkage, or definitions with
AvailableExternallyLinkage.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199204 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-14 11:55:03 +00:00
Juergen Ributzka
4ab3e6c164 [anyregcc] Fix callee-save mask for anyregcc
Use separate callee-save masks for XMM and YMM registers for anyregcc on X86 and
select the proper mask depending on the target cpu we compile for.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198985 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-11 01:00:27 +00:00
Peter Collingbourne
1e3037f0be Implement function prefix data as an IR feature.
Previous discussion:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-July/063909.html

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

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190773 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-16 01:08:15 +00:00
Sean Silva
a7aec400a7 docs: Fix long standing linking antipattern.
Before we learned about :doc:, we used :ref: and put a dummy link at the
top of each page. Don't do that anymore.

This fixes PR14891 as a special case.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172162 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-11 02:28:08 +00:00
Joe Abbey
2db2749c67 Better 80cols... *sigh*
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168373 91177308-0d34-0410-b5e6-96231b3b80d8
2012-11-20 18:14:15 +00:00
Joe Abbey
8162cf4567 Fixing a broken link.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@168372 91177308-0d34-0410-b5e6-96231b3b80d8
2012-11-20 17:51:08 +00:00
Jan Wen Voung
0919f22dec Fix a typo in bitcode docs, from 165814.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165944 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-15 16:47:58 +00:00
Jan Wen Voung
780c798222 Add bitcode instruction encoding documentation for module version
0 and 1.  Followup to 165739.

git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@165814 91177308-0d34-0410-b5e6-96231b3b80d8
2012-10-12 18:13:17 +00:00
Bill Wendling
0ca9927a71 Sphinxify the bitcode format document.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159340 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-28 08:43:12 +00:00