It hass been a longstanding principle in LLVM that the presence of
debug info shall not affect code generation. This patch brings the
Swift frontend closer to this ideal:
- unconditionally emit shadow copies
- unconditionally bind type metadata
The extra allocas, bitcasts, geps, and stores being emitted get
optimized away when compiling at anything but -Onone. There are few
use-cases for compiling at -Onone without -g, so this shouldn't affect
performance for any real-world use-cases.
And update the existential container's initializeWithTake implementation
in the runtime. After only allowing bitwise takable values in the
inline buffer we can use memcpy to move existential container values.
rdar://31414907
SR-343
This adds the dllstorage annotations on the tests. This first pass gets
most of the IRGen tests passing on Windows (though has dependencies on
other changes). However, this allows for the changes to be merged more
easily as we cannot regress other platforms here.
I am going to leave in the infrastructure around this just in case. But there is
no reason to keep this in the tests themselves. I can always just revert this
and I don't think merge conflicts are likely due to previous work I did around
the tooling for this.
* Remove RegisterPreservingCC. It was unused.
* Remove DefaultCC from the runtime. The distinction between C_CC and DefaultCC
was unused and inconsistently applied. Separate C_CC and DefaultCC are
still present in the compiler.
* Remove function pointer indirection from runtime functions except those
that are used by Instruments. The remaining Instruments interface is
expected to change later due to function pointer liability.
* Remove swift_rt_ wrappers. Function pointers are an ABI liability that we
don't want, and there are better ways to get nonlazy binding if we need it.
The fully custom wrappers were only needed for RegisterPreservingCC and
for optimizing the Instruments function pointers.
If we want it to be a Swift function, we'll have to thunk in the
runtime when using a system implementaton like dispatch_once_f,
since the function pointer ABIs could be different, depending on
the target. Dealing with that, or avoiding it on a per-target basis,
is more complexiity than a micro-optimization of the slow path of
this builtin could possibly be worth.
It is a runtime function defined in swift. This currently did not have
ABI implications because the ABI happened to be compatible but ...
SR-6235
rdar://problem/35222489
On architectures where the calling convention uses the same argument register as
return register this allows the argument register to be live through the calls.
We use LLVM's 'returned' attribute on the parameter to facilitate this.
We used to perform this optimization via an optimization pass. This was ripped
out some time ago around commit 955e4ed652.
By using LLVM's 'returned' attribute on swift_*retain, we get the same
optimization from the LLVM backend.
It's more appropriate to use `Unknown` refcounting, which we correctly handle in the face of non-ObjC-interop elsewhere. Fixes a problem where the Linux standard library would contain an unresolvable reference to `objc_release`.
Having such a builtin makes it easier for the optimizer to reason about what is actually happening.
I plan to add later some optimizations which can optimize pieces of code dominated by such a check.
