Refactor Immediate Mode to use the Materialization Unit API,
materializing the entire `SILModule` corresponding to the script
when the `main` symbol is looked up.
Some frameworks that previously had a separate swift overlay have been
merged in macOS 14. This is causing symbols to not resolve if using the
new SDK but running on an older OS in immediate mode. Ideally we would
handle this automatically in JITLink as is done by the system linker,
but in the meantime add a workaround to load the correct libraries
manually.
rdar://110371405
Using a virutal output backend to capture all the outputs from
swift-frontend invocation. This allows redirecting and/or mirroring
compiler outputs to multiple location using different OutputBackend.
As an example usage for the virtual outputs, teach swift compiler to
check its output determinism by running the compiler invocation
twice and compare the hash of all its outputs.
Virtual output will be used to enable caching in the future.
When looking for a Swift module on disk, we were scanning all module search paths if they contain the module we are searching for. In a setup where each module is contained in its own framework search path, this scaled quadratically with the number of modules being imported. E.g. a setup with 100 modules being imported form 100 module search paths could cause on the order of 10,000 checks of `FileSystem::exists`. While these checks are fairly fast (~10µs), they add up to ~100ms.
To improve this, perform a first scan of all module search paths and list the files they contain. From this, create a lookup map that maps filenames to the search paths they can be found in. E.g. for
```
searchPath1/
Module1.framework
searchPath2/
Module1.framework
Module2.swiftmodule
```
we create the following lookup table
```
Module1.framework -> [searchPath1, searchPath2]
Module2.swiftmodule -> [searchPath2]
```
This is for the 'freestanding' build to stop assuming the platform has argc/argv.
- Introduce a new sub-library, libswiftCommandLineSupport.a
- Move stubs/CommandLine.cpp into this library
- Conditionally embed it into libswiftCore
- Conditionally embed it into libswiftPrivateLibcExtras if not in libswiftCore to support testing
- Add SWIFT_STDLIB_HAS_COMMANDLINE CMake (and build-script) flag
* add the (still empty) libswift package
* add build support for libswift in CMake
* add libswift to swift-frontend and sil-opt
The build can be controlled with the LIBSWIFT_BUILD_MODE cmake variable: by default it’s “DISABLE”, which means that libswift is not built. If it’s “HOSTTOOLS”, libswift is built with a pre-installed toolchain on the host system.
Add a debugging mechanism that enables the JIT to dump the LLVM IR and
object files to enable debugging the JIT. This makes it easier to debug
the JIT mode failures. The idea was from Lang Hames!
With an inverted pipeline, IRGen needs to be able
to compute the linker directives itself, so sink
it down such that it can be computed by the
`IRGenDescriptor`.
With an inverted pipeline, IRGen needs to be able
to compute the linker directives itself, so sink
it down such that it can be computed by the
`IRGenDescriptor`.
Delete all of the formalism and infrastructure around maintaining our own copy of the global context. The final frontier is the Builtins, which need to lookup intrinsics in a given scratch context and convert them into the appropriate Swift annotations and types. As these utilities have wormed their way through the compiler, I have decided to leave this alone for now.
All of this is in service of working around a pile of deficiencies in LLVM's Module Linker, and LLVMContext abstractions. And because we're just gonna scrap this code soon anyways, it's probably not worth the effort to push on these bugs to block the broader cleanup here.
The LLVM Linker currently does not support linking modules allocated in different contexts. This appears to be motivated in part by LLVM's lack of a facility to clone a module from one context to another. This, in turn, appears to be motivated in part by LLVMContext's lack of a robust notion of identity - which makes it harder than it needs to be to detect the mismatch.
However, it is not impossible to clone a module across contexts. We need to get creative and round-trip the module through some serialization layer. Out of convenience, that layer is currently textual IR, though bitcode would work equally well.
Given that it is no longer under the caller's control which LLVMContext we generate code in, put all the above together to arrive at an egregious hack that clones the module into the LLVMContext the REPL expects.
swift::GeneratedModule encapsulates an llvm::Module, llvm::LLVMContext
pair that must live and die together. It has convenient accessors for
projecting the module and context components. The meat of this type is
the two conversion functions, which transfer ownership of either the
module component to the caller or the module and context to ORCJIT.
This is because ORC enforces an ownership contract that is distinct from
LLVM's rather wild ownership story for modules and their associated
contexts. See http://llvm.org/docs/ORCv2.html#how-to-use-threadsafemodule-and-threadsafecontext
LLJIT is a simple LLVM IR JIT. Its interface is similar to MCJIT, but its
implementation is based on LLVM's newer ORC APIs. This initial patch does not
make use of any of LLJIT/ORC's advanced features, but will provide better
diagnostics when JIT'd code fails to link. Once LLJIT has proven usable in
this basic configuration we can start experimenting with more advanced
features, including lazy compilation.
The REPL was using the CompilerInstance to stash this parameter, then it would immediately move it into IRGen. Drop the setter and pass this data directly.
The library does not have the lib prefix in Windows, so the immediate
mode was not finding the file. This was making the new tests in
tests/Driver/options.swift fail on Windows. The tests pass after this
change.
Notice that it seems to load the host standard library, so restricting
the change to Windows seems to be OK and should not affect
cross-compilation. Windows was already hardcoding ".dll" as the library
extension, disregarding the target, anyway.
