introduce a common superclass, SILNode.
This is in preparation for allowing instructions to have multiple
results. It is also a somewhat more elegant representation for
instructions that have zero results. Instructions that are known
to have exactly one result inherit from a class, SingleValueInstruction,
that subclasses both ValueBase and SILInstruction. Some care must be
taken when working with SILNode pointers and testing for equality;
please see the comment on SILNode for more information.
A number of SIL passes needed to be updated in order to handle this
new distinction between SIL values and SIL instructions.
Note that the SIL parser is now stricter about not trying to assign
a result value from an instruction (like 'return' or 'strong_retain')
that does not produce any.
So far we did this only for loop headers, but there are cases where we need it for all blocks to prevent infinite loops in SimplifyCFG.
rdar://problem/34576609
The reason to do this is:
1. The check in SILInliner if we can inline can be done without triggering
side-effects.
2. This enables us to know if inlining will succeed before attempting to inline.
This enables for arguments to be adjusted with new SILInstructions and the like
before inlining occurs. I use this in a forthcoming patch that updates mandatory
inlining for ownership.
rdar://31521023
The etymology of these terms isn't about race, but "black" = "blocked"
and "white" = "allowed" isn't really a good look these days. In most
cases we weren't using these terms particularly precisely anyway, so
the rephrasing is actually an improvement.
"Accessibility" has a different meaning for app developers, so we've
already deliberately excised it from our diagnostics in favor of terms
like "access control" and "access level". Do the same in the compiler
now that we aren't constantly pulling things into the release branch.
This commit changes the 'Accessibility' enum to be named 'AccessLevel'.
This is a separate optimization that detects short-lived temporaries that can be eliminated.
This is necessary now that SILGen no longer performs basic RValue forwarding in some cases.
SR-5508: Performance regression in benchmarks caused by removing SILGen peephole for LoadExpr in +0 context
This bug was caught by the SIL verifier. Any invocation of a NoReturn function should be followed by an `unreachable` instruction.
Fixes rdar://problem/33591235
Instead of having the complicated logic of finding the end of an object's lifetime we now use the existing ValueLifetimeAnalysis and StackNesting tools.
This simplifies the implementation a lot and does not use dominator and post-dominator trees anymore.
It's not a NFC because the way how to ensure proper nesting of stack allocations is now different.
To correct the stack nesting, the deallocations are moved down (instead of moving the allocations up).
Also it's now required that there is a final release for the allocation on all paths (which was not the case in some hand-written SIL tests).
Computation of dead-end blocks and escape analysis are now only done on demand. This saves compile time in case a function has no alloc_refs at all.
In dead-array elimination we assume that the array allocation is post-dominated by all its final releases.
The only exception are branches to dead-end ("unreachable") blocks. So we just ignored all paths which didn't end up in a final release.
Now we explicitly pass the set of dead-end blocks and just ignore those blocks.
This is safer and it's also needed in the upcoming re-write of StackPromotion.
This patch started with a suggestion from Adrian Prantl to adapt to
LLVM r307953. The code has changed more since then so I modified it
to get it to build and I also fixed up StackPromotion to deal with related
changes. (I did not search back very far but it looks like the StackPromotion
change may have been a latent bug that did not matter much until recent
changes started using the function parameter.)
1) PostOrderAnalysis is not invalidated after splitting critical edges. This let the data flow solver omit new inserted blocks.
2) Handle infinite loops in the CFG correctly. So that we don’t insert random release instructions into such CFG pathes.
https://bugs.swift.org/browse/SR-5187
rdar://problem/32713742
