WebAssembly doesn't reserve low addresses but without "extra inhabitants" of
the pointer representation, runtime performance and memory footprint are
worse. So assume that compiler driver uses wasm-ld and --global-base=1024 to
reserve low 1KB.
Starting with Android 11, AArch64 placed a tag in the top byte of pointers to
allocations, which has been slowly rolling out to more devices and collides
with Swift's tags. Moving these tags to the second byte works around this
problem.
Commit the platform definition and build script work necessary to
cross-compile for arm64_32.
arm64_32 is a variant of AARCH64 that supports an ILP32 architecture.
Poison sentinel value recognized by LLDB as a former reference to a
potentially deinitialized object. It uses no spare bits and cannot point to
readable memory.
This is not ABI per-se but does stay in-sync with LLDB. If it becomes
out-of-sync, then users won't see a friendly diagnostic when
inspecting references past their lifetime.
* Adds support for generating code that uses swiftasync parameter lowering.
* Currently only arm64's llvm lowering supports the swift_async_context_addr intrinsic.
* Add arm64e pointer signing of updated swift_async_context_addr.
This commit needs the PR llvm-project#2291.
* [runtime] unittests should use just-built compiler if the runtime did
This will start to matter with the introduction of usage of swiftasync parameters which only very recent compilers support.
rdar://71499498
Previously we had a single mask for all x86-64 targets which included both the top and bottom bits. This accommodated simulators, which use the top bit, while macOS uses the bottom bit, but reserved one bit more than necessary on each. This change breaks out x86-64 simulators from non-simulators and reserves only the one bit used on each.
rdar://problem/34805348 rdar://problem/29765919
* Reduce array abstraction on apple platforms dealing with literals
Part of the ongoing quest to reduce swift array literal abstraction
penalties: make the SIL optimizer able to eliminate bridging overhead
when dealing with array literals.
Introduce a new classify_bridge_object SIL instruction to handle the
logic of extracting platform specific bits from a Builtin.BridgeObject
value that indicate whether it contains a ObjC tagged pointer object,
or a normal ObjC object. This allows the SIL optimizer to eliminate
these, which allows constant folding a ton of code. On the example
added to test/SILOptimizer/static_arrays.swift, this results in 4x
less SIL code, and also leads to a lot more commonality between linux
and apple platform codegen when passing an array literal.
This also introduces a couple of SIL combines for patterns that occur
in the array literal passing case.
The high half of the address space is used by the kernel in these architectures, and it would be useful for us to be able to pack small values into places the ABI otherwise requires a refcountable pointer, such as closures and maybe refcounted existentials.
MachO uses ;, other targets use #. This would result in a rather
cryptic error message when building libdispatch for Linux AArch64:
<inline asm>:1:27: error: unexpected token in argument list
mov fp, fp ; marker for objc_retainAutoreleaseReturnValue
^
LLVM ERROR: Error parsing inline asm
Be more conservative in terms of masking ISAs. This reduces tight coupling with the objc runtime. This commit adds the required calls to IRGen and the runtime, and a test case to make sure IRGen is correct.
This patch adds powerpc64le Linux support. While the patch also adds
the matching powerpc64 bits, there are endian issues that need to be
sorted out.
The PowerPC LLVM changes for the swift ABI (eg returning three element
non-homogeneous aggregates) are still in the works, but a simple LLVM
fix to allow those aggregates results in swift passing all but 8
test cases.
The absolute symbol reference isn't needed on OS X >=10.9 or any iOS/watchOS, which are the only Darwin platforms Swift targets. Fixes rdar://problem/22339638.
Swift SVN r31367
We now let Clang handle C calling conventions, so we don't need a special value for this to kludge CG types into working. No reason for this to vary across archs for now.
Swift SVN r28397
This matches how dispatch_once works in C, dramatically cutting the cost of a global accessor by avoiding the runtime call in the hot path and giving the global a unique branch for the CPU to predict away. For now, only do this for Darwin; non-ObjC platforms don't necessarily expose their "done" value as ABI like ours do.
While we're here, change "once" to take a thin function pointer. We don't ever emit global initializers with context dependencies, and this simplifies the runtime glue between swift_once and dispatch_once/std::call_once a bit.
Swift SVN r28166
This has been long in coming. We always had it in IRGenOpts (in string form).
We had the version number in LangOpts for availability purposes. We had to
pass IRGenOpts to the ClangImporter to actually create the right target.
Some of our semantic checks tested the current OS by looking at the "os"
target configuration! And we're about to need to serialize the target for
debugging purposes.
Swift SVN r24468
IRGen uses a typedef, SpareBitVector, for its principal
purpose of tracking spare bits. Other uses should not
use this typedef, and I've tried to follow that, but I
did this rewrite mostly with sed and may have missed
some fixups.
This should be almost completely NFC. There may be
some subtle changes in spare bits for witness tables
and other off-beat pointer types. I also fixed a bug
where IRGen thought that thin functions were two
pointers wide, but this wouldn't have affected anything
because we never store thin functions anyway, since
they're not a valid AST type.
This commit repplies r24305 with two fixes:
- It fixes the computation of spare bits for unusual
integer types to use the already-agreed-upon type
size instead of recomputing it. This fixes the
i386 stdlib build. Joe and I agreed that we should
also change the size to use the LLVM alloc size
instead of the next power of 2, but this patch
does not do that yet.
- It changes the spare bits in function types back
to the empty set. I'll be changing this in a
follow-up, but it needs to be tied to runtime
changes. This fixes the regression test failures.
Swift SVN r24324
IRGen uses a typedef, SpareBitVector, for its principal
purpose of tracking spare bits. Other uses should not
use this typedef, and I've tried to follow that, but I
did this rewrite mostly with sed and may have missed
some fixups.
This should be almost completely NFC. There may be
some subtle changes in spare bits for witness tables
and other off-beat pointer types. I also fixed a bug
where IRGen thought that thin functions were two
pointers wide, but this wouldn't have affected anything
because we never store thin functions anyway, since
they're not a valid AST type.
Swift SVN r24305
Just injecting a new protocol descriptor into an already-running ObjC runtime isn't a good idea, since the runtime might have already canonized the protocol somewhere else, and it won't recognize that classes conform to protocols it doesn't know about.
Swift SVN r23313
instances of Swift subclasses of ObjC classes.
We were already doing this in the runtime. This patch
unhides the runtime's mask word (swift_isaMask) and makes
IR-gen take advantage of it when it can.
Swift SVN r21592
Don't use spare bits on platforms that use ObjC tagged pointers when an enum payload involves a class-constrained existential, archetype, or ObjC-defined class type. If a payload is of a Swift-defined class type, we can still assume it's a real pointer and use its spare bits. Add an @unsafe_no_objc_tagged_pointer attribute that can be applied to protocols to denote that existentials bounded by that protocol can use spare bits; this is necessary to preserve the layout of bridged Array and Dictionary types, which should not be bound to tagged pointer types in practice (fingers crossed). Fixes <rdar://problem/16270219>.
Swift SVN r18781
Start out with pointer spare bits, heap object alignment, null page size, and ObjC reserved bits, and provide static values for X86-64 and for a worst-case generic platform.
Swift SVN r7833
