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)
IRGen sets up the `llvm::TargetOptions` by itself, rather than copying
them from the Clang instance (it has to do this, at present, because
Clang doesn't provide a way to get it to initialise one).
Unfortunately, it didn't set `UseInitArray`, which when linking with
GNU `ld` or `gold` is *fine* because those linkers automatically
convert `.ctors` and `.dtors` sections into `.init_array` and
`.fini_array` respectively. *However*, `lld` does *not* do this
conversion, so when using `lld`, if the compiler generates a
constructor or destructor function, it won't be called(!)
The fix is to set `UseInitArray` properly; I chose to copy the setting
from Clang, just in case Clang knows of a reason why it shouldn't be
`true`.
rdar://123504095
Without doing this, `__Swift_AST` gets stripped from the output.
We also need to call `IGM.finalize()` before `::performLLVM()` in the
`createSwiftModuleObjectFile()` function, so that we update the
section to mark it as retained.
rdar://123504095
It's not thread safe and can cause false alarms in case multiple modules exist in different threads. E.g. when building swiftmodules from interfaces.
The leaking check is not important anymore because the builder APIs enforce that instructions are not leaking.
I.e. it's not possible to create an instruction without inserting it into a basic block. Also, it's not possible to remove an instruction from a block without deleting it.
rdar://122169263
Previously, if a request R evaluated itself N times, we would emit N
"circular reference" diagnostics. These add no value, so instead let's
cache the user-provided default value on the first circular evaluation.
This changes things slightly so that instead of returning an
llvm::Expected<Request::OutputType>, various evaluator methods take
a callback which can produce the default value.
The existing evaluateOrDefault() interface is unchanged, and a new
evaluateOrFatal() entry point replaces
llvm::cantFail(ctx.evaluator(...)).
Direct callers of the evaluator's operator() were updated to pass in
the callback. The benefit of the callback over evaluateOrDefault() is
that if the default value is expensive to constuct, like a dummy
generic signature, we will only construct it in the case where a
cycle actually happened, otherwise we just delete the callback.
(cherry picked from commit b8fcf1c709efa6cd28e1217bd0efe876f7c0d2b7)
