As the complexity of the analysis is more than linear with the number of blocks, disable it for functions with > 2000 basic blocks.
In this case inlining will be less aggressive.
SR-10209
rdar://problem/49522869
The main thing to notice about these changes is that I always picked the debug
scope associated with the location we were using. They should always be in
sync.
When compiling SwiftOnoneSupport, issue errors for missing functions which are expected in the module.
This ensures ABI compatibility.
rdar://problem/48924409
When compiling the OnoneSupport library, the compiler checks for @_semantics("prespecialize.X") attributes to pre-specialize function X.
rdar://problem/48924409
Add the list of symbols from the swift-5.0 release and only use that symbols to refer to pre-specializations in a Onone build.
This ensures that future Onone executables can link to an old swift 5.0 libswiftSwiftOnoneSupport library.
rdar://problem/48924409
This is an obvious drive-by fix. It will crash when building
Foundation after I commit changes to the pipeline. My attempts at
creating a unit test were unsuccessful because it depends on some
interaction between inlining and specialization heuristics.
The ownership kind is Any for trivial types, or Owned otherwise, but
whether a type is trivial or not will soon depend on the resilience
expansion.
This means that a SILModule now uniques two SILUndefs per type instead
of one, and serialization uses two distinct sentinel IDs for this
purpose as well.
For now, the resilience expansion is not actually used here, so this
change is NFC, other than changing the module format.
This could probably be an error, but I am leaving it to preserve previous
behavior. The reason I am hoisting this is that I am hoisting it before we
potentially split a basic block. When we evaluate if we can early exit, we
should never do work before we know that we will emit /something/.
This code today only handles the following two instructions:
1. checked_cast_addr_br
2. unconditional_checked_cast_addr
We were asserting that the source/dest of these values were addresses... but
they are obviously are!
I think that this is a result of previous refactorings. This code has a long
time assert in it that Src (since 2016) is an address and for a long time the bridged type has
always been an object (since 2015). So, thus we know that the following is always true.
SILBridgedTy != Src->getType()
I also removed a level of indentation. NFC.
The 2015 commit hash is: 2dd38eee0e (the original commit).
The 2016 commit hash is: 506ab9809f
For context, String, Nil, Bool, and Int already behave this way.
Note: Swift can compile against 80 or 64 bit floats as the builtin
literal type. Thus, it was necessary to capture this bit somehow in the
FloatLiteralExpr. This was done as another Type field capturing this
info.
