`.swift_ast` section is now recognized as a "metadata" section by LLVM's
object emission. On WebAssembly, metadata symbols must not appear in the
object file symbol table. Therefore, change the linkage of the
`@__Swift_AST` global from InternalLinkage to PrivateLinkage to avoid
exposing the symbol.
555eaef3ab
Calling setupLLVMOptimizationRemarks overwrites the MainRemarkStreamer
in the LLVM context. This prevents LLVM from serializing the remark meta
information for the already emitted SIL remarks into the object file.
Without the meta information bitstream remarks don't work correctly.
Instead, emit SIL remarks and LLVM remarks to the same RemarkSerializer,
and keep the file stream alive until after CodeGen.
Android before API 29 and a few other platforms don't support native TLS, so
fall back to LLVM's emulated TLS there, just like clang does. Also, make sure
`-Xcc -f{no-,}emulated-tls` flags passed in are applied to control what the
Swift compiler does.
This achieves the same as clang's `-fdebug-info-for-profiling`, which
emits DWARF discriminators to aid in narrowing-down which basic block
corresponds to a particular instruction address. This is particularly
useful for sampling-based profiling.
rdar://135443278
Adds sections `__TEXT,__swift_as_entry`, and `__TEXT,__swift_as_ret` that
contain relative pointers to async functlets modelling async function entries,
and function returns, respectively.
Emission of the sections can be trigger with the frontend option
`-Xfrontend -enable-async-frame-push-pop-metadata`.
This is done by:
* IRGen adding a `async_entry` function attribute to async functions.
* LLVM's coroutine splitting identifying continuation funclets that
model the return from an async function call by adding the function
attribute `async_ret`. (see #llvm-project/pull/9204)
* An LLVM pass that keys off these two function attribute and emits the
metadata into the above mention sections.
rdar://134460666
Based on prior evaluation, this optimization always increases code
size. It splits out blocks and introduces calls, which always adds
extra instructions to shuffle values for calling conventions and
to make the actual call/return. Apple clang avoids the optimization
in `-Oz`, which I think is pretty close to what Swift's `-Osize`
really means.
rdar://128870792
Synthesized files are treated as not having a parent source file, but that can cause issues for macro code. The declarations will have the source file of their use site declared as parent source file, which means they should be emitted into the same IGM. If we don't use the correct IGM, we can get inconsistencies when referencing the generated code, which will cause linking issues.
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
