maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/test/CodeGen/X86/dllexport-x86_64.ll

104 lines
2.4 KiB
LLVM
Raw Normal View History

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. llvm-svn: 199218
2014-01-14 23:22:47 +08:00
; RUN: llc -mtriple x86_64-pc-win32 < %s | FileCheck -check-prefix=CHECK -check-prefix=WIN32 %s
; RUN: llc -mtriple x86_64-pc-mingw32 < %s | FileCheck -check-prefix=CHECK -check-prefix=MINGW %s
; CHECK: .text
define void @notExported() {
ret void
}
; CHECK: .globl f1
define dllexport void @f1() {
ret void
}
; CHECK: .globl f2
define dllexport void @f2() unnamed_addr {
ret void
}
; CHECK: .globl lnk1
define linkonce_odr dllexport void @lnk1() {
ret void
}
; CHECK: .globl lnk2
define linkonce_odr dllexport void @lnk2() alwaysinline {
ret void
}
; CHECK: .globl weak1
define weak_odr dllexport void @weak1() {
ret void
}
; CHECK: .data
; CHECK: .globl Var1
@Var1 = dllexport global i32 1, align 4
MC: Emit COFF section flags in the "proper" order COFF section flags are not idempotent: 'rd' will make a read-write section because 'd' implies write 'dr' will make a read-only section because 'r' disables write llvm-svn: 228490
2015-02-07 16:26:40 +08:00
; CHECK: .rdata,"dr"
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. llvm-svn: 199218
2014-01-14 23:22:47 +08:00
; CHECK: .globl Var2
@Var2 = dllexport unnamed_addr constant i32 1
; CHECK: .comm Var3
@Var3 = common dllexport global i32 0, align 4
; CHECK: .globl WeakVar1
@WeakVar1 = weak_odr dllexport global i32 1, align 4
; CHECK: .globl WeakVar2
@WeakVar2 = weak_odr dllexport unnamed_addr constant i32 1
Handle dllexport for global aliases llvm-svn: 199219
2014-01-14 23:23:25 +08:00
; CHECK: .globl alias
; CHECK: alias = notExported
@alias = dllexport alias void()* @notExported
; CHECK: .globl alias2
; CHECK: alias2 = f1
@alias2 = dllexport alias void()* @f1
; CHECK: .globl alias3
Prevent alias from pointing to weak aliases. This adds back r204781. Original message: Aliases are just another name for a position in a file. As such, the regular symbol resolutions are not applied. For example, given define void @my_func() { ret void } @my_alias = alias weak void ()* @my_func @my_alias2 = alias void ()* @my_alias We produce without this patch: .weak my_alias my_alias = my_func .globl my_alias2 my_alias2 = my_alias That is, in the resulting ELF file my_alias, my_func and my_alias are just 3 names pointing to offset 0 of .text. That is *not* the semantics of IR linking. For example, linking in a @my_alias = alias void ()* @other_func would require the strong my_alias to override the weak one and my_alias2 would end up pointing to other_func. There is no way to represent that with aliases being just another name, so the best solution seems to be to just disallow it, converting a miscompile into an error. llvm-svn: 204934
2014-03-27 23:26:56 +08:00
; CHECK: alias3 = notExported
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. llvm-svn: 209007
2014-05-17 03:35:39 +08:00
@alias3 = dllexport alias void()* @notExported
Handle dllexport for global aliases llvm-svn: 199219
2014-01-14 23:23:25 +08:00
; CHECK: .weak weak_alias
; CHECK: weak_alias = f1
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. llvm-svn: 214355
2014-07-31 06:51:54 +08:00
@weak_alias = weak_odr dllexport alias void()* @f1
Handle dllexport for global aliases llvm-svn: 199219
2014-01-14 23:23:25 +08:00
Emit data or code export directives based on the type. Currently we look at the Aliasee to decide what type of export directive to use. It seems better to use the type of the alias directly. This is similar to how we handle the alias having the same address but other attributes (linkage, visibility) from the aliasee. With this patch it is now possible to do things like target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-pc-windows-msvc" @foo = global [6 x i8] c"\B8*\00\00\00\C3", section ".text", align 16 @f = dllexport alias i32 (), [6 x i8]* @foo !llvm.module.flags = !{!0} !0 = metadata !{i32 6, metadata !"Linker Options", metadata !1} !1 = metadata !{metadata !2, metadata !3} !2 = metadata !{metadata !"/DEFAULTLIB:libcmt.lib"} !3 = metadata !{metadata !"/DEFAULTLIB:oldnames.lib"} llvm-svn: 209600
2014-05-25 20:49:07 +08:00
@blob = global [6 x i8] c"\B8*\00\00\00\C3", section ".text", align 16
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. llvm-svn: 210062
2014-06-03 10:41:57 +08:00
@blob_alias = dllexport alias bitcast ([6 x i8]* @blob to i32 ()*)
Handle dllexport for global aliases llvm-svn: 199219
2014-01-14 23:23:25 +08:00
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. llvm-svn: 199218
2014-01-14 23:22:47 +08:00
; CHECK: .section .drectve
Teach LTOModule to emit linker flags for dllexported symbols, plus interface cleanup. This change unifies how LTOModule and the backend obtain linker flags for globals: via a new TargetLoweringObjectFile member function named emitLinkerFlagsForGlobal. A new function LTOModule::getLinkerOpts() returns the list of linker flags as a single concatenated string. This change affects the C libLTO API: the function lto_module_get_*deplibs now exposes an empty list, and lto_module_get_*linkeropts exposes a single element which combines the contents of all observed flags. libLTO should never have tried to parse the linker flags; it is the linker's job to do so. Because linkers will need to be able to parse flags in regular object files, it makes little sense for libLTO to have a redundant mechanism for doing so. The new API is compatible with the old one. It is valid for a user to specify multiple linker flags in a single pragma directive like this: #pragma comment(linker, "/defaultlib:foo /defaultlib:bar") The previous implementation would not have exposed either flag via lto_module_get_*deplibs (as the test in TargetLoweringObjectFileCOFF::getDepLibFromLinkerOpt was case sensitive) and would have exposed "/defaultlib:foo /defaultlib:bar" as a single flag via lto_module_get_*linkeropts. This may have been a bug in the implementation, but it does give us a chance to fix the interface. Differential Revision: http://reviews.llvm.org/D10548 llvm-svn: 241010
2015-06-30 06:04:09 +08:00
; WIN32: /EXPORT:f1
; WIN32-SAME: /EXPORT:f2
; WIN32-SAME: /EXPORT:lnk1
; WIN32-SAME: /EXPORT:lnk2
; WIN32-SAME: /EXPORT:weak1
; WIN32-SAME: /EXPORT:Var1,DATA
; WIN32-SAME: /EXPORT:Var2,DATA
; WIN32-SAME: /EXPORT:Var3,DATA
; WIN32-SAME: /EXPORT:WeakVar1,DATA
; WIN32-SAME: /EXPORT:WeakVar2,DATA
; WIN32-SAME: /EXPORT:alias
; WIN32-SAME: /EXPORT:alias2
; WIN32-SAME: /EXPORT:alias3
; WIN32-SAME: /EXPORT:weak_alias
; WIN32-SAME: /EXPORT:blob_alias
; MINGW: -export:f1
; MINGW-SAME: -export:f2
; MINGW-SAME: -export:lnk1
; MINGW-SAME: -export:lnk2
; MINGW-SAME: -export:weak1
; MINGW-SAME: -export:Var1,data
; MINGW-SAME: -export:Var2,data
; MINGW-SAME: -export:Var3,data
; MINGW-SAME: -export:WeakVar1,data
; MINGW-SAME: -export:WeakVar2,data
; MINGW-SAME: -export:alias
; MINGW-SAME: -export:alias2
; MINGW-SAME: -export:alias3
; MINGW-SAME: -export:weak_alias
; MINGW-SAME: -export:blob_alias"