[swift-dev] Proposal: Opaque SIL values

John McCall rjmccall at apple.com
Wed Jan 25 22:38:35 CST 2017

> On Jan 25, 2017, at 9:13 PM, Joe Groff via swift-dev <swift-dev at swift.org> wrote:
> Looks great. One nitpick:
>> Naturally, opaque types must limit some optimizations, such as inlining.
> I don't see how opaque types by themselves prevent inlining. You can inline a generic into another generic, or a function using a resilient type into another function.
>> This would hide part of the ABI from SIL. However, reabstraction must be exposed to SIL. Doing so simplifies IRGen, allows the SIL optimizer to improve code within thunks, and allows the SIL optimizer can perform function signature optimizations across calls.
> Perhaps in the future, we could delay the lowering of reabstraction as well to a late lowering pass. Many times, inlining and specialization eliminate the need for reabstractions by eliminating the call boundaries and generic abstraction shifts, and it would be nice not to have to clean up these unnecessary reabstractions by never emitting them in the first place.

Hmm.  This is a tricky question.  I think we'd want to keep *bridging* early, at least.  For other kinds of representation change, delaying them has some benefits, but I wonder if those benefits are significant once we have an SSA representation, because that will enable us to also have a "reabstract" instruction which will make the peepholes basically trivial.


More information about the swift-dev mailing list