This adjusts the runtime function declaration handling to track the
owning module for the well known functions. This allows us to ensure
that we are able to properly identify if the symbol should be imported
or not when building the shared libraries. This will require a
subsequent tweak to allow for checking for static library linkage to
ensure that we do not mark the symbol as DLLImport when doing static
linking.
`ReadOnly, ArgMemOnly` previously meant `can only read argument memory`.
But with the rebranch changes, this became `(can only read *all* memory)
and (can read or write argument memory)`. Use `ArgMemReadOnly` for this
instead.
To expand on this, these attributes (prior to memory effects) used to be
split into two. There was the *kind* of access, eg.
```
readnone
readonly
writeonly
```
and the accessed *location*, eg.
```
argmemonly
inaccessiblememonly
inaccessiblemem_or_argmemonly
```
So `RuntimeFunctions.def` would use `ReadOnly, ArgMemOnly` to mean `can
only read argument memory`.
In the previous rebranch commits, this was changed such that `ReadOnly`
mapped to `MemoryEffectsBase::readOnly()` and `ArgMemOnly` to
`MemoryEffectsBase::argMemOnly()`.
And there lies the issue -
- `MemoryEffectsBase::readOnly()` == `MemoryEffectsBase(Ref)` ie. all
locations can only read
- `MemoryEffectsBase::argMemOnly()` == `MemoryEffectsBase(ArgMem,
ModRef)`, ie. can only access argument memory
But then OR'ing those together this would become:
```
ArgMem: ModRef, InaccessibleMem: Ref, Other: Ref
```
rather than the previously intended:
```
ArgMem: Ref, InaccessibleMem: NoModRef, Other: NoModRef
```
In preparation for moving to llvm's opaque pointer representation
replace getPointerElementType and CreateCall/CreateLoad/Store uses that
dependent on the address operand's pointer element type.
This means an `Address` carries the element type and we use
`FunctionPointer` in more places or read the function type off the
`llvm::Function`.
- 3e1c787b3160bed4146d3b2b5f922aeed3caafd7 `arg_operands` was replaced with `args`.
- 80ea2bb57450a65cc724565ecfc9971ad93a3f15 `get*Attributes` was replaced with `get*Attrs`
When backward deploying to an OS that may not have these entry points, weak-link them so that they
can be used conditionally in availability contexts that check for them.
rdar://problem/50731151
rdar://problem/48833545
From the LLVM Manual regarding tail/musttail : "Both markers imply that the callee does not access allocas from the caller”
Swift’s LLVMARCContract just marks all the calls it creates as tail call without any analysis and/or checking if we are allowed to do that. This created an interesting runtime crash that was a pain to debug - story time:
I traced a runtime crash back to Swift’s LLVMARCContract, but could not grok why the transformation there is wrong: we replaced two consecutive _swift_bridgeObjectRelease(x) calls with _swift_bridgeObjectRelease_n(x, 2), which is a perfectly valid thing to do.
I noticed that the new call is marked as a tail call, disabling that portion of the pass “solved” the runtime crash, but I wanted to understand *why*:
This code worked:
pushq $2
popq %rsi
movq -168(%rbp), %rdi
callq _swift_bridgeObjectRelease_n
leaq -40(%rbp), %rsp
popq %rbx
popq %r12
popq %r13
popq %r14
popq %r15
popq %rbp
retq
While this version crashed further on during the run:
movq -168(%rbp), %rdi
leaq -40(%rbp), %rsp
popq %rbx
popq %r12
popq %r13
popq %r14
popq %r15
popq %rbp
jmp _swift_bridgeObjectRelease_n
As you can see, the call is the last thing we do before returning, so nothing appeared out of the ordinary at first…
Dumping the heap object at the release basic block looked perfectly fine: the ref count was 2 and all the fields looked valid.
However, when we reached the callee the value was modified / dumping it showed it changed somewhere. Which did not make any sense.
Setting up a memory watchpoint on the heap object and/or its reference count did not get us anywhere: the watchpoint triggered on unrelated code in the entry to the callee..
I then realized what’s going on, here’s a an amusing reproducer that you can checkout in LLDB:
Experiment 1:
Setup a breakpoint at leaq -40(%rbp), %rsp
Dump the heap object - it looks good
Experiment 2:
Rerun the same test with a small modification:
Setup a breakpoint at popq %rbx (the instruction after leaq, do not set a breakpoint at leaq)
Dump the heap object - it looks bad!
So what is going on there? The SIL Optimizer changed an alloc_ref instruction into an alloc_ref [stack], which is a perfectly valid thing to do.
However, this means we allocated the heap object on the stack, and then tail-called into the swift runtime with said object. After having modified the stack pointer in the caller’s epilogue.
So why does experiment 2 show garbage? We’ve updated the stack pointer, and it just so happens that we are after the red zone on the stack. When the breakpoint is hit (the OS passes control back to LLDB), it is perfectly allowed to use the memory where the heap object used to reside.
Note: I then realized something even more concerning, that we were lucky not have hit so far: not only did we not check if we are allowed to mark a call as ’tail’ in this situation, which could have been considered a corner case, we could have if we have not promoted it from heap to stack, but we marked *ALL* the call instructions created in this pass as tail call even if they are not the last thing that occurred in the calling function! Looking at the LVMPasses/contract.ll test case, which is modified in this PR, we see some scary checks that are just wrong: we are checking if a call is marked as ‘tail’ in the middle of the function, then check the rest of the function in CHECK-NEXT lines. Knowing full well that the new ‘tail call’ is not the last thing that should execute in the caller.
We used to represent these just as normal LLVM functions, e.x.:
declare objc_object* @objc_retain(objc_object*)
declare void @objc_release(objc_object*)
Recently, special objc intrinsics were added to LLVM. This pass updates these
small (old) passes to use the new intrinsics.
This turned out to not be too difficult since we never create these
instructions. We only analyze them, move them, and delete them.
rdar://47852297
We used to represent these just as normal LLVM functions, e.x.:
declare objc_object* @objc_retain(objc_object*)
declare void @objc_release(objc_object*)
Recently, special objc intrinsics were added to LLVM. This pass updates these
small (old) passes to use the new intrinsics.
This turned out to not be too difficult since we never create these
instructions. We only analyze them, move them, and delete them.
rdar://47852297
These functions don't accept local variable heap memory, although the names make it sound like they work on anything. When you try, they mistakenly identify such things as ObjC objects, call through to the equivalent objc_* function, and crash confusingly. This adds Object to the name of each one to make it more clear what they accept.
rdar://problem/37285743
Since we introduce the declaration for bridgeRetainN, its result type may be out
of sync with bridgeRetain's. This means that when we perform a RAUW of one for
the other, the types do not match and we get an LLVM error. Instead, just cast
the bridgeRetainN's type to bridgeRetain's result type.
rdar://40507281
Sometimes when running ARCContract on LLVM-IR certain required declarations will
be deleted. This triggers an assert that makes it difficult to work on running
test cases through the pass.
Instead, if we can not find by name the runtime function we are looking for,
recreate the named type as an opaque struct. Since we can not find the function
by name, we can assume that either this is a runtime function that we are the
only passes that create them or that the declarations were dead. Thus, there is
no earlier data, so we can just create a new opaque struct type and use pointers
to that struct_type. If we later need to merge this with another module that did
not delete that type definition, LLVM IR will set the type's body. Since we are
just using pointers to the type, there will be no codegen differences.
rdar://40491584
* 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.
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.
Fixed for the difference of Cygwin with other Windows variants (MSVC,
Itanium, MinGW).
- The platform name is renamed to "cygwin" from "windows" which is used
for searching the standard libraries.
- The consideration for DLL storage class (DllExport/DllImport) is not
required for Cygwin and MinGW. There is no problem when linking in
these environment.
- Cygwin should use large memory model as default.(This may be changed
if someone ports to 32bit)
- Cygwin and MinGW should use the autolink feature in the sameway of
Linux due to the linker's limit.
Add initial support for modelling DLL Storage semantics for global values. This
is needed to support the indirect addressing mechanism used on Windows.
Properly lower reference counting SIL instructions with nonatomic attribute as invocations of corresponding non-atomic reference counting runtime functions.
Each runtime function definition in RuntimeFunctions.def states which calling convention
should be used for this runtime function. But IRGen and LLVMPasses were not always
properly propagating this declared calling convention all the way down to llvm's Call instructions.
In many cases, the standard C convention was set for the call irrespective of the actual calling
convention defined for a given runtime function. As a result, incorrect code was generated.
This commit tries to fix all those places, where such a mismatch was found. In many cases this is
achieved by defining a helper function CreateCall in such a way that makes sure that the call instruction
gets the same calling convention as the one used by its callee operand.
Make use of the re-usable functionality provided by IRGen. This ensures that LLVM IR generated by IRGen and
LLVMPasses for runtime functions declarations or wrappers is always in sync.
This reverts commit r32132. It broke tests:
Swift :: 1_stdlib/FloatingPoint.swift.gyb
Swift :: 1_stdlib/NSStringAPI.swift
Swift :: 1_stdlib/Runtime.swift
Swift :: Interpreter/SDK/CoreGraphics_CGFloat.swift
Swift SVN r32142
when an object is passed to unknownRetain and retain, the unknownRetain
can be strength reduced to retain. same for unknownRelease and release.
Swift SVN r32087
