Re: [swift-dev] Proposal: Opaque SIL values

> On Jan 26, 2017, at 8:33 AM, John McCall wrote: > >> On Jan 24, 2017, at 2:10 PM, Andrew Trick via swift-dev > > wrote: >> I’m sending out a proposal for fundamentally changing SIL. This work feeds >> into generic code optimization, resilience, semantic ARC, and SI

Re: [swift-dev] Proposal: Opaque SIL values

> On Jan 26, 2017, at 12:45 AM, Andrew Trick wrote: > > >> On Jan 25, 2017, at 6:13 PM, Joe Groff wrote: >> >>> 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 anothe

Re: [swift-dev] Proposal: Opaque SIL values

> On Jan 24, 2017, at 2:10 PM, Andrew Trick via swift-dev > wrote: > I’m sending out a proposal for fundamentally changing SIL. This work feeds > into generic code optimization, resilience, semantic ARC, and SIL ownership. > This was discussed at length back in October—some info went out on >

Re: [swift-dev] Proposal: Opaque SIL values

> On Jan 25, 2017, at 4:22 PM, Karl Wagner wrote: > > >> On 24 Jan 2017, at 20:10, Andrew Trick via swift-dev > > wrote: >> >> I’m sending out a proposal for fundamentally changing SIL. This work feeds >> into generic code optimization, resilience, semantic ARC, an

Re: [swift-dev] Proposal: Opaque SIL values

> On Jan 25, 2017, at 6:13 PM, Joe Groff wrote: > >> 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 f

Re: [swift-dev] Proposal: Opaque SIL values

> On Jan 25, 2017, at 9:13 PM, Joe Groff via swift-dev > 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 funct

Re: [swift-dev] Proposal: Opaque SIL values

On Jan 24, 2017, at 10:58 PM, Andrew Trick wrote: > > That would come about when the program wants to use the same lvalue for > multiple real values. I don't expect many problems with simple opaque types. > The only way to mutate them is either passing them @inout or returning them > @out. We

Re: [swift-dev] Proposal: Opaque SIL values

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

Re: [swift-dev] Proposal: Opaque SIL values

> On 24 Jan 2017, at 20:10, Andrew Trick via swift-dev > wrote: > > I’m sending out a proposal for fundamentally changing SIL. This work feeds > into generic code optimization, resilience, semantic ARC, and SIL ownership. > This was discussed at length back in October—some info went out on >

Re: [swift-dev] Proposal: Opaque SIL values

> On Jan 24, 2017, at 8:56 PM, Chris Lattner wrote: > > >> On Jan 24, 2017, at 11:10 AM, Andrew Trick via swift-dev >> mailto:swift-dev@swift.org>> wrote: >> >> I’m sending out a proposal for fundamentally changing SIL. This work feeds >> into generic code optimization, resilience, semantic

Re: [swift-dev] Proposal: Opaque SIL values

> On Jan 24, 2017, at 11:10 AM, Andrew Trick via swift-dev > wrote: > > I’m sending out a proposal for fundamentally changing SIL. This work feeds > into generic code optimization, resilience, semantic ARC, and SIL ownership. > This was discussed at length back in October—some info went out o

[swift-dev] Proposal: Opaque SIL values

I’m sending out a proposal for fundamentally changing SIL. This work feeds into generic code optimization, resilience, semantic ARC, and SIL ownership. This was discussed at length back in October—some info went out on swift-dev—but I realized there hasn’t been a formal proposal. So here it is. I w