[IRGen][Runtime] Adjust the ObjC reserved bits on x86-64 to exactly match what the target uses. #19540
Conversation
|
@swift-ci please test |
|
Build failed |
|
Build failed |
|
Curse you, |
mikeash
force-pushed
the
reserved-bits-refinement
branch
from
e3fbedf to
8ec3f75
Compare
|
@swift-ci please test |
|
Build failed |
|
Build failed |
stdlib/public/SwiftShims/System.h
Outdated
| // Systems exist which use either bit. | ||
| #define SWIFT_ABI_X86_64_OBJC_RESERVED_BITS_MASK 0x8000000000000001ULL | ||
| // Objective-C normally reserves the low bit for tagged pointers, but | ||
| // instead reserves the high bit on iOS simulators. |
There was a problem hiding this comment.
I don't think this is correct; doesn't it use the high bit everywhere but x86_64 Mac, so that objc_msgSend can do the clever "branch if nil or negative" trick?
There was a problem hiding this comment.
I meant that within the context of x86-64, so it's sort of right, but not exactly clear. I think I was trying to be excessively general or something. I'll fix it.
mikeash
force-pushed
the
reserved-bits-refinement
branch
4 times, most recently
from
a43d849 to
2d97218
Compare
| /// BridgeObject masks | ||
| #ifdef __x86_64__ | ||
| // x86-64 uses a different #define from the others | ||
| #define _swift_BridgeObject_TaggedPointerBits SWIFT_ABI_X86_64_BRIDGEOBJECT_TAG |
There was a problem hiding this comment.
This part doesn't really make sense either. BridgeObject just always uses the high bit as a tag, regardless of what the underlying tagged pointer mechanism uses.
There was a problem hiding this comment.
Agreed. I think I was too caught up in how it was previously defined. I've redone it to be totally separate from anything ObjC.
mikeash
force-pushed
the
reserved-bits-refinement
branch
from
2d97218 to
95f5058
Compare
|
@swift-ci please test |
|
Build failed |
|
Build failed |
| @@ -180,6 +197,15 @@ static_assert(alignof(HeapObject) == alignof(void*), | |||
| (__swift_uintptr_t) SWIFT_ABI_DEFAULT_OBJC_RESERVED_BITS_MASK | |||
| #define _swift_abi_ObjCReservedLowBits \ | |||
| (unsigned) SWIFT_ABI_DEFAULT_OBJC_NUM_RESERVED_LOW_BITS | |||
|
|
|||
| #if defined(__LP64__) || defined(__LLP64__) | |||
There was a problem hiding this comment.
Nitpick: I think we've been using __POINTER_WIDTH__ == 64 elsewhere in the runtime.
There was a problem hiding this comment.
Ah, thanks! I tried to see what was being used but didn't find that. LP64 is also used in a few places but for more platform-specific purposes, so this is definitely better.
mikeash
force-pushed
the
reserved-bits-refinement
branch
from
95f5058 to
5ba06be
Compare
|
@swift-ci please test |
|
Build failed |
|
Build failed |
mikeash
force-pushed
the
reserved-bits-refinement
branch
from
5ba06be to
e3594ab
Compare
|
Messed up the 32-bit mask while I was in there, now fixed. |
|
@swift-ci please test |
…atch what the target uses. 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
|
Build failed |
mikeash
force-pushed
the
reserved-bits-refinement
branch
from
e3594ab to
fa4178c
Compare
|
Build failed |
|
@swift-ci please test |
|
Build failed |
|
Build failed |
|
Tests passed but the Mac run still failed with what looks like a spurious error. Trying again. |
|
@swift-ci please test os x |
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.
This PR also includes a new substitution in
lit.cfgto allow some tests to distinguish between simulator and non-simulator targets. This was needed because x86-64 simulator and non-simulator now generate slightly different output for some tests.rdar://problem/34805348 rdar://problem/29765919