> On Jan 25, 2017, at 9:13 PM, Joe Groff via swift-dev <swift-dev@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. John. _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
