Type annotations for instruction operands are omitted, e.g.
```
%3 = struct $S(%1, %2)
```
Operand types are redundant anyway and were only used for sanity checking in the SIL parser.
But: operand types _are_ printed if the definition of the operand value was not printed yet.
This happens:
* if the block with the definition appears after the block where the operand's instruction is located
* if a block or instruction is printed in isolation, e.g. in a debugger
The old behavior can be restored with `-Xllvm -sil-print-types`.
This option is added to many existing test files which check for operand types in their check-lines.
This is a large patch; I couldn't split it up further while still
keeping things working. There are four things being changed at
once here:
- Places that call SILType::isAddressOnly()/isLoadable() now call
the SILFunction overload and not the SILModule one.
- SILFunction's overloads of getTypeLowering() and getLoweredType()
now pass the function's resilience expansion down, instead of
hardcoding ResilienceExpansion::Minimal.
- Various other places with '// FIXME: Expansion' now use a better
resilience expansion.
- A few tests were updated to reflect SILGen's improved code
generation, and some new tests are added to cover more code paths
that previously were uncovered and only manifested themselves as
standard library build failures while I was working on this change.
The basic theory here is as follows:
- The resilience expansion never changes the lowered type, only the
SIL type category (object or address). This means that function
types always pass resilient values indirectly regardless of
expansion, etc.
- The getTypeLowering() methods all take an optional 'forExpansion'
parameter. Soon, these will become non-optional and I'll audit all
call sites to pass the right expansion; for convenience, the
entry points on SILFunction will pass the right expansion.
Places I need to revisit and pass the right expansion in are marked
as 'FIXME: Expansion'.
For now, this just fixes a SILCombiner bug. After some more plumbing
this will enable SILGen to produce better code.
Progress on <rdar://problem/24057844>,
<https://bugs.swift.org/browse/SR-261>.
This utility is generally a horrible idea but even worse the
callers were not doing anything to ensure the required
invariants actually held.
Add a new canReplaceLoadSequence() method and chek it in the
right places.
For example:
struct ResilientStruct {
var singleField: Int
public static let x = ResilientStruct(singleField: 27)
}
The generated (resilient) getter for x should just return a 27 (wrapped in a struct) and not lazily initialize a global variable.
rdar://problem/46712028