[WebAssembly] Initial wasm linker implementation

This linker backend is still a work in progress but is
enough to link simple programs including linking against
library archives.

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

llvm-svn: 318539

Author: sbc100

lld/CMakeLists.txt

@@ -223,4 +223,4 @@ add_subdirectory(docs)
 add_subdirectory(COFF)
 add_subdirectory(ELF)
 add_subdirectory(MinGW)
-
+add_subdirectory(wasm)

lld/CODE_OWNERS.TXT

@@ -17,3 +17,6 @@ N: Lang Hames, Nick Kledzik
 E: lhames@gmail.com, kledzik@apple.com
 D: Mach-O backend
 
+N: Sam Clegg
+E: sbc@chromium.org
+D: WebAssembly backend (wasm/*)

lld/docs/NewLLD.rst

@@ -1,5 +1,5 @@
-The ELF and COFF Linkers
-========================
+The ELF, COFF and Wasm Linkers
+==============================
 
 The ELF Linker as a Library
 ---------------------------
@@ -33,11 +33,12 @@ between speed, simplicity and extensibility.
 
   We implemented the linkers as native linkers for each file format.
 
-  The two linkers share the same design but do not share code.
+  The linkers share the same design but share very little code.
   Sharing code makes sense if the benefit is worth its cost.
-  In our case, ELF and COFF are different enough that we thought the layer to
-  abstract the differences wouldn't worth its complexity and run-time cost.
-  Elimination of the abstract layer has greatly simplified the implementation.
+  In our case, the object formats are different enough that we thought the layer
+  to abstract the differences wouldn't be worth its complexity and run-time
+  cost.  Elimination of the abstract layer has greatly simplified the
+  implementation.
 
 * Speed by design
 

lld/docs/WebAssembly.rst

@@ -0,0 +1,36 @@
+WebAssembly lld port
+====================
+
+Note: The WebAssembly port is still a work in progress and is be lacking
+certain features.
+
+The WebAssembly version of lld takes WebAssembly binaries as inputs and produces
+a WebAssembly binary as its output.  For the most part this port tried to mimic
+the behaviour of traditional ELF linkers and specifically the ELF lld port.
+Where possible that command line flags and the semantics should be the same.
+
+
+Object file format
+------------------
+
+The format the input object files that lld expects is specified as part of the
+the WebAssembly tool conventions
+https://github.com/WebAssembly/tool-conventions/blob/master/Linking.md.
+
+This is object format that the llvm will produce when run with the
+``wasm32-unknown-unknown-wasm`` target.  To build llvm with WebAssembly support
+currently requires enabling the experimental backed using
+``-DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD=WebAssembly``.
+
+
+Missing features
+----------------
+
+There are several key features that are not yet implement in the WebAssembly
+ports:
+
+- COMDAT support.  This means that support for C++ is still very limited.
+- Function stripping.  Currently there is no support for ``--gc-sections`` so
+  functions and data from a given object will linked as a unit.
+- Section start/end symbols.  The synthetic symbols that mark the start and
+  of data regions are not yet created in the output file.

lld/docs/index.rst

@@ -5,13 +5,14 @@ LLD is a linker from the LLVM project. That is a drop-in replacement
 for system linkers and runs much faster than them. It also provides
 features that are useful for toolchain developers.
 
-The linker supports ELF (Unix), PE/COFF (Windows) and Mach-O (macOS)
-in descending order of completeness. Internally, LLD consists of three
-different linkers. The ELF port is the one that will be described in
-this document. The PE/COFF port is almost complete except the lack of
-the Windows debug info (PDB) support. The Mach-O port is built based
-on a different architecture than the ELF or COFF ports. For the
-details about Mach-O, please read :doc:`AtomLLD`.
+The linker supports ELF (Unix), PE/COFF (Windows), Mach-O (macOS) and
+WebAssembly in descending order of completeness. Internally, LLD consists of
+several different linkers. The ELF port is the one that will be described in
+this document. The PE/COFF port is almost complete except the lack of the
+Windows debug info (PDB) support. The WebAssembly port is still a work in
+progress (See :doc:`WebAssembly`).  The Mach-O port is built based on a
+different architecture than the others. For the details about Mach-O, please
+read :doc:`AtomLLD`.
 
 Features
 --------
@@ -172,5 +173,6 @@ document soon.
 
    NewLLD
    AtomLLD
+   WebAssembly
    windows_support
    ReleaseNotes

lld/include/lld/Common/Driver.h

@@ -33,6 +33,11 @@ namespace mach_o {
 bool link(llvm::ArrayRef<const char *> Args,
           llvm::raw_ostream &Diag = llvm::errs());
 }
+
+namespace wasm {
+bool link(llvm::ArrayRef<const char *> Args, bool CanExitEarly,
+          llvm::raw_ostream &Diag = llvm::errs());
+}
 }
 
 #endif

lld/test/lit.cfg.py

@@ -39,7 +39,7 @@
 llvm_config.use_lld()
 
 tool_patterns = [
-    'llvm-as', 'llvm-mc', 'llvm-nm',
+    'llc', 'llvm-as', 'llvm-mc', 'llvm-nm',
     'llvm-objdump', 'llvm-pdbutil', 'llvm-readobj', 'obj2yaml', 'yaml2obj']
 
 llvm_config.add_tool_substitutions(tool_patterns)
@@ -67,6 +67,7 @@
                           'Mips': 'mips',
                           'PowerPC': 'ppc',
                           'Sparc': 'sparc',
+                          'WebAssembly': 'wasm',
                           'X86': 'x86'})
      ])
 

lld/test/wasm/Inputs/archive1.ll

@@ -0,0 +1,7 @@
+declare i32 @bar() local_unnamed_addr #1
+
+define i32 @foo() local_unnamed_addr #0 {
+entry:
+  %call = tail call i32 @bar() #2
+  ret i32 %call
+}

lld/test/wasm/Inputs/archive2.ll

@@ -0,0 +1,7 @@
+declare i32 @foo() local_unnamed_addr #1
+
+define i32 @bar() local_unnamed_addr #0 {
+entry:
+  %call = tail call i32 @foo() #2
+  ret i32 %call
+}

lld/test/wasm/Inputs/call-indirect.ll

@@ -0,0 +1,18 @@
+target datalayout = "e-m:e-p:32:32-i64:64-n32:64-S128"
+target triple = "wasm32-unknown-unknown-wasm"
+
+@indirect_bar = hidden local_unnamed_addr global i32 ()* @bar, align 4
+
+; Function Attrs: norecurse nounwind readnone
+define hidden i32 @bar() #0 {
+entry:
+  ret i32 1
+}
+
+; Function Attrs: nounwind
+define hidden void @call_bar_indirect() local_unnamed_addr #1 {
+entry:
+  %0 = load i32 ()*, i32 ()** @indirect_bar, align 4
+  %call = tail call i32 %0() #2
+  ret void
+}

lld/test/wasm/Inputs/hello.ll

@@ -0,0 +1,18 @@
+; Wasm module generated from the following C code:
+;   void puts(const char*);
+;   void hello() { puts("hello\n"); }
+
+target datalayout = "e-m:e-p:32:32-i64:64-n32:64-S128"
+target triple = "wasm32-unknown-unknown-wasm"
+
+@hello_str = unnamed_addr constant [7 x i8] c"hello\0A\00", align 1
+
+; Function Attrs: nounwind
+define hidden void @hello() local_unnamed_addr #0 {
+entry:
+  tail call void @puts(i8* getelementptr inbounds ([7 x i8], [7 x i8]* @hello_str, i32 0, i32 0))
+  ret void
+}
+
+; Function Attrs: nounwind
+declare void @puts(i8* nocapture readonly) local_unnamed_addr #1