The prior emission strategy produced some scary SIL where
we have a copy of uninitialized memory:
```
ignored_use %14
%16 = alloc_stack $T
unreachable
bb1:
copy_addr [take] %16 to [init] %0
dealloc_stack %16
```
I assume this was done to dodge the SILVerifier, which
will catch a take of an uninitialized address, had the
alloc_stack been in any reachable predecessor.
We already have a representation for an undefined value
in SIL, so I'd rather use that than try to sneak one
past the verifier.
This adjusted emission also is opaque values friendly,
as it doesn't assume the result value is an address.
resolves rdar://162239557
This is a new case that comes up with `InlineArray`, since an `InlineArray`
with unknown count but known trivial element type is trivial but still
address-only due to its unknown size. We are inconsistent about whether
we emit formal copies or not of these values; they should generally
be unnecessary as long as the memory location of a value is sufficiently
long-lived, but the SIL verifier still reasonably considers a `[take]` as
an invalidation of the memory, even though at runtime a take is a no-op.
Since the take is unnecessary, we can just not take when we copy out of
a trivial address location. Fixes#84141 | rdar://160007939.
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 generates significantly better code directly out of SILGen, at
the cost of having to reimplement a little bit of the argument-emission
logic to handle default arguments. But it also neatly sidesteps the
problems we have with splitting tuple RValues when the tuple contains
a pack expansion, which will require some significant surgery to RValue
to fix. That, in turn, fixes rdar://121489308.
I don't like that this method exists, and I'd like to rip it out
in favor of expecting an opaque lowering, but I'm worried about
doing that this late in 5.9.
Fixes rdar://107290521
My original test case here used a memberwise initializer, but those
use their own logic for binding and forward parameters which will
need to be updated separately.
More missing infrastructure. In this case, it's really *existing*
missing infrastructure, though; we should have been imploding tuples
this way all along, given that we're doing it in the first place.
I don't like that we're doing all these extra tuple copies. I'm not
sure yet if they're just coming out of SILGen and eliminated immediately
after in practice; maybe so. Still, it should be obvious that they're
unnecessary.
This required quite a bit of infrastructure for emitting this kind of
tuple expression, although I'm not going to claim they really work yet;
in particular, I know the RValue constructor is going to try to explode
them, which it really shouldn't.
It also doesn't include the caller side of returns, for which I'll need
to teach ResultPlan to do the new abstraction-pattern walk. But that's
next.
