Commit Graph

16 Commits

Author SHA1 Message Date
Michael Gottesman
26a734e58e [sil] Rename ValueOwnershipKind::{Any,None} 2019-10-25 10:28:25 -07:00
Slava Pestov
16d5716e71 SIL: Use the best resilience expansion when lowering types
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.
2019-04-26 22:47:59 -04:00
Slava Pestov
8915f96e3e SIL: Replace SILType::isTrivial(SILModule) with isTrivial(SILFunction) 2019-03-12 01:16:04 -04:00
Michael Gottesman
0af0d5fddc [ownership] Replace ValueOwnershipKind::Trivial with ValueOwnershipKind::Any.
In a previous commit, I banned in the verifier any SILValue from producing
ValueOwnershipKind::Any in preparation for this.

This change arises out of discussions in between John, Andy, and I around
ValueOwnershipKind::Trivial. The specific realization was that this ownership
kind was an unnecessary conflation of the a type system idea (triviality) with
an ownership idea (@any, an ownership kind that is compatible with any other
ownership kind at value merge points and can only create). This caused the
ownership model to have to contort to handle the non-payloaded or trivial cases
of non-trivial enums. This is unnecessary if we just eliminate the any case and
in the verifier separately verify that trivial => @any (notice that we do not
verify that @any => trivial).

NOTE: This is technically an NFC intended change since I am just replacing
Trivial with Any. That is why if you look at the tests you will see that I
actually did not need to update anything except removing some @trivial ownership
since @any ownership is represented without writing @any in the parsed sil.

rdar://46294760
2018-12-04 23:01:43 -08:00
John McCall
3162b513a9 Strengthen some assertions with cleanup scopes; NFC. 2018-10-25 21:50:00 -07:00
John McCall
fae2ec3b38 Assorted minor improvements to the cleanup system. 2018-08-22 01:55:10 -04:00
David Zarzycki
8c0c55539f [SIL] NFC: Rename misleading getSwiftRValueType() to getASTType()
Reference storage types are not RValues. Also, use more SILType helper
methods to avoid line wrap.
2018-05-04 08:14:38 -04:00
Arnold Schwaighofer
e36655fddc SILGen: Remove PostponedCleanup in favor or the SIL pass that fixes
closure lifetimes.

SILGen will now unconditionally emit

  %cvt = convert_escape_to_noescape [guaranteed] %op

instructions. The mandatory ClosureLifetimeFixup pass ensures that %op's
lifetime spans %cvt's uses.

The code in DefiniteInitialization that handled a subset of cases is
removed.
2018-04-13 13:44:09 -07:00
Arnold Schwaighofer
025a8b909a Fix PostponedCleanup and use it in more places.
It can't be moved because there are pointers to it
2018-02-13 04:19:59 -08:00
Arnold Schwaighofer
64943836ba SILGen: Support for trivial @noescape function types
- Emit a withoutActuallyEscapingClosure partial apply
This is to convert an @noescape closure to an escaping closure.
This needs to be done in preparation of @noescape closure contexts
becoming trivial.

- Insert escaping to noescape conversions

- Fix SILGen for @noescape

- Postpone closure cleanups to outside the argument scope

- Apply postponement recursively for closures passed to subscripts

- Only skip applying escapeness conversions for Swift thick functions

- Fix parameter convention for noescape closures in thunks

Part of:
SR-5441
rdar://36116691
2018-02-13 04:19:59 -08:00
Slava Pestov
fa8d04cd8d SILGen: Remove Scope::popPreservingValues() 2017-11-20 12:59:03 -05:00
Andrew Trick
c6f82f8f85 [sil-opaque-values] Fix SIL ownership in reabstraction thunks.
Emit a borrow scope whenever exploding tuples in to a list of arguments.

I spent a lot of time attempting to refactor the reabstraction thunk generation
code with code that handles RValue. However, there is a subtle difference in how
tuples are handled when they are packed into a single "RValue" as opposed to a
list of arguments.

Eventually, I ditched that effort because of subtle complexity and fell back on
Michael's suggestion of handling the extra thunk-sepcific work inside
Scope.popPreservingValues. This will just go away though once we have the
'destructure' instruction.
2017-09-10 16:01:35 -07:00
Michael Gottesman
dc8b1c2c3a [silgen] When pushing an RValue through a scope, use dealloc_box on any boxes we create instead of destroy_value.
It is only safe to perform a destroy_value on an alloc_box that contains an
initialized value. We preserve the original cleanups for the value we are
pushing through the scope implying that the box will not contain an initialized
value when its lifetime ends (just like an alloc_stack). Thus we must use
dealloc_box here.

The surprising thing about tracking down this error is that I was not hitting
any memory issues at -Onone. Instead what was happening was that at -O, we were
miscompiling (creating non-dominating uses of SSA values) in the face of an
address being taken twice.

This does not seem to hit any SILGen tests today (I hit this when testing a
patch I am trying to land today).

rdar://31521023
2017-09-04 10:46:37 -07:00
Michael Gottesman
4127e92f61 [silgen] Teach Scope how to push InContext values through a scope being popped. 2017-08-18 22:04:53 -07:00
Michael Gottesman
4fcf4bb186 [silgen] Teach Scope::popPreservingValue(RValue &&rv) how to handle address only values.
rdar://33358110
2017-08-14 13:24:43 -07:00
Michael Gottesman
3907c49748 [silgen] Teach SILGen how to push a +1 rvalue through a scope like we already can do for +1 managed values.
rdar://33358110
2017-08-08 13:13:40 -07:00