Commit Graph

8 Commits

Author SHA1 Message Date
Rafael Espindola 3c9be62d24 Set dso_local for runtime function.
This is another case where there is special logic for adding dllimport
and so we cannot use setGVProperties.

llvm-svn: 328036
2018-03-20 20:27:30 +00:00
Reid Kleckner fb93154bf1 [MS] Don't escape MS C++ names with \01
It is not needed after LLVM r327734. Now it will be easier to copy-paste
IR symbol names from Clang.

llvm-svn: 327738
2018-03-16 20:36:49 +00:00
Rafael Espindola abdb322438 Set dso_local on tls init functions.
We copy the visibility, so copying the dso_local flag seems the
natural thing to do.

llvm-svn: 326961
2018-03-07 23:18:06 +00:00
Rafael Espindola 922f2aa9b2 Bring r325915 back.
The tests that failed on a windows host have been fixed.

Original message:

Start setting dso_local for COFF.

With this there are still some GVs where we don't set dso_local
because setGVProperties is never called. I intend to fix that in
followup commits. This is just the bare minimum to teach
shouldAssumeDSOLocal what it should do for COFF.

llvm-svn: 325940
2018-02-23 19:30:48 +00:00
Rafael Espindola 43ce3a3a4d Revert "Start setting dso_local for COFF."
This reverts commit r325915.

It will take some time to fix the failures on a windows host.

llvm-svn: 325929
2018-02-23 18:09:29 +00:00
Rafael Espindola 004d240b6a Start setting dso_local for COFF.
With this there are still some GVs where we don't set dso_local
because setGVProperties is never called. I intend to fix that in
followup commits. This is just the bare minimum to teach
shouldAssumeDSOLocal what it should do for COFF.

llvm-svn: 325915
2018-02-23 15:32:32 +00:00
Martell Malone b22e600484 CodeGenCXX: no default dllimport storage for mingw
GNU frontends don't have options like /MT, /MD
This fixes a few link error regressions with libc++ and libc++abi

Reviewers: rnk, mstorsjo, compnerd

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

llvm-svn: 317398
2017-11-04 02:15:49 +00:00
Saleem Abdulrasool 6cb0744934 CodeGen: fix runtime function dll storage
Properly attribute DLL storage to runtime functions.  When generating the
runtime function, scan for an existing declaration which may provide an explicit
declaration (local storage) or a DLL import or export storage from the user.
Honour that if available.  Otherwise, if building with a local visibility of the
public or standard namespaces (-flto-visibility-public-std), give the symbols
local storage (it indicates a /MT[d] link, so static runtime).  Otherwise,
assume that the link is dynamic, and give the runtime function dllimport
storage.

This allows for implementations to get the correct storage as long as they are
properly declared, the user to override the import storage, and in case no
explicit storage is given, use of the import storage.

llvm-svn: 289776
2016-12-15 06:59:05 +00:00