LLVM seems to determine a variable instance as a combination of DILocalVariable
and DILocation. Therefore if multiple llvm.dbg.declare have the same
variable/location parameters, they are considered to be referencing the same
instance of variable.
Swift IRGen emits a set of llvm.dbg.declare calls for every variable
instance (with unique SILDebugScope), so it is important that these calls have
distinct variable/location parameters. Otherwise their DIExpression may be
incorrect when treated as referencing the same variable. For example, if they
have a DIExpression with fragments, we will see this as multiple declarations of
the same fragment. LLVM detects this and crashes with assertion failure:
DwarfExpression.cpp:679: void llvm::DwarfExpression::addFragmentOffset(const
llvm::DIExpression *): Assertion `FragmentOffset >= OffsetInBits &&
"overlapping or duplicate fragments"' failed.
The patch resolves#55703. The LIT test (debug_scope_distinct.swift) is the
reproducer from that issue.
For `alloc_ref [bare] [stack]` and `global_value [bare]` omit the object header initialization.
The `bare` flag means that the object header is not used.
This was already done with a peephole optimization inside IRGen for `global_value`. But now rely on the SIL `bare` flag.
The `bare` attribute indicates that the object header is not used throughout the lifetime of the value.
This means, no reference counting operations are performed on the object and its metadata is not used.
The header of bare objects doesn't need to be initialized.
SelectEnumInstBase will be templated in the next commit.
Instead of using templated SelectEnumInstBase everywhere, introduce
a new wrapper type SelectEnumOperation.
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
Macro-generated extensions are hoisted to file scope, because extensions are
not valid in nested scopes. Callers of 'visitAuxiliaryDecls' assume that the
auxiliary decls are in the same decl context as the original, which is clearly
not the case for extensions, and it leads to issues like visiting extension at
the wrong time during SILGen. The extensions are already added to the top-level
decls, so we don't need to visit them as auxiliary decls, and we can type-check
macro-expanded decls at the end of visitation in TypeCheckDeclPrimary.
* [IRGen+Runtime] Layout string getEnumTag for fixed size enums subset
getEnumTag impl for layout strings of fixed sized enums that use a function to fetch the enum tag
* Fix potential UB in IRGen
SIL variables can be split by SILSROA into separate allocations, each having
op_fragment expressions in debug_value (VarInfo.DIExpr). These allocations can
be further split by IRGen (multiple values in Storage argument).
These "nested" fragments refer to the same DI variable, so it is important to
merge them for the LLVM IR DI expression. The compiler used to ignore fragment
expressions from SIL when IRGen fragments were also present. This led to
incorrect DI info generation, and for some cases even triggered assertions in
LLVM X86 CodeGen:
DwarfExpression.cpp:679: void llvm::DwarfExpression::addFragmentOffset(const
llvm::DIExpression *): Assertion `FragmentOffset >= OffsetInBits &&
"overlapping or duplicate fragments"' failed.
The patch fixes issue #64642. The LIT test is a reduced reproducer from that issue.
`std::set::insert` isn't exposed into Swift, because it returns an instance of an unsafe type.
This change adds a Swift overload of `insert` for `std::set` and `std::unordered_set` that has the return type identical to `Swift.Set.insert`: a tuple of `(inserted: Bool, memberAfterInsert: Element)`.
rdar://111036912
* [IRGen] Use EnumImplStrategy to generate getEnumTag function for layout strings
rdar://110794898
The implementation in TypeLayout seems to have a bug causing wrong tags to be returned on 32 bit systems.
* Don't use unsupported types in tests
- Renames ExperimentalPlatformCCallingConvention to
PlatformCCallingConvention.
- Removes non-arm calling convention support as this feature is working
around a clang bug for some arm triples which we hope to see resolved.
- Removes misleading MetaVarName from platform-c-calling-convention
argument.
- Replaces other uses of LLVM::CallingConv::C with
IGM.getOptions().PlatformCCallingConvention().
Adds a new swift-frontend flag to allow users to choose which calling
convention is used to make c function calls. This hidden flag is called
`-experimental-platform-c-calling-convention`.
This behavior is needed to workaround rdar://109431863 (Swift-frontend
produces trapping llvm ir for non-trapping sil). The root cause of this
issue is that IRGen always emits c function calls with llvm's default C
calling convention. However clang may select a different (incompatible)
calling convention for the function, eventually resulting--via
InstCombine and SimplifyCFG--in a trap instead of the function call.
This failure mode is most readily seen with the triple
`armv7em-apple-none-macho` when attempting to call functions taking
struct arguments. Example unoptimized ir below:
```llvm-ir
call void @bar([4 x i32] %17, i32 2), !dbg !109
...
define internal arm_aapcs_vfpcc void @bar(
[4 x i32] %bar.coerce, i32 noundef %x)
```
In the future it would be better to use the clang importer or some other
tool to determine the calling convention for each function instead of
setting the calling convention frontend invocation wide.
Note: I don't know for sure whether or not clang should be explicitly
annotating these functions with a calling convention instead of
aliasing C to mean ARM_AAPCS_VFP for this particular combination of
`-target`, `-mfloat-abi`, and `-mcpu`.
Based on https://github.com/apple/swift/pull/66409
With the observation that the pre-opaque world was using bitcast as an
indication that the storage type and the type of the variable were
different. We can recover this information from the storage type of the
alloca and the storage type of the type info.
SIL Functions are serialized in canonical SIL before they have their final ABI
adjusted for large function arguments. Large function argument ABI is adjusted
to be indirect as part of the transition from canonical SIL to lowered SIL. This
means that if we deserialize a function from another module in canonical SIL and
attempt to call it in IRGen we will call it with the wrong ABI implying if we
reference any fields of the type in the deinit we will most likely crash (among
other potential issues).
This patch fixes the issue by changing IRGen to not lazily deserialize the
moveonly deinit table and its associated functions. Instead if we do not have
our table already deserialized, we just call the function's deinit via the
destroy value deinit table.
rdar://110496872
