Pure/isUniquelyReferenced and C libraries


(Michael Gottesman) #1

Background

···

==========

I have recently been thinking about clang attributes and how we can take advantage of the work other people have done in terms of putting attributes in their headers especially in terms of ARC.

The two most pervasive such attributes are the const/pure attributes. Trivially the const attribute (since it can not read global memory) can not read or write reference counts. But what about pure? For those who are unfamiliar pure in "c" means that a function's value is only dependent on its arguments and reading global memory. Being able to only read global memory is an interesting property from the ARC perspective since there is only one ARC function that reads a reference count that is exported from the runtime, the uniqueness check. All other ways to read/write a reference count are either restricted to pure swift code or if they are allowed in C++ code write to reference counts. If we were able to say that it is undefined behavior to invoke isUniquelyReferenced from non-swift runtime functions, we immediately could get nice speed boosts when using imported c code that is pure without any further work on the maintainers part.

Proposal

State that is is undefined behavior to reference isUniquelyReferenced in a non-swift function in 3rd party libraries.

Thoughts?
Michael


(Michael Gottesman) #2

Background

I have recently been thinking about clang attributes and how we can take advantage of the work other people have done in terms of putting attributes in their headers especially in terms of ARC.

The two most pervasive such attributes are the const/pure attributes. Trivially the const attribute (since it can not read global memory) can not read or write reference counts. But what about pure? For those who are unfamiliar pure in "c" means that a function's value is only dependent on its arguments and reading global memory. Being able to only read global memory is an interesting property from the ARC perspective since there is only one ARC function that reads a reference count that is exported from the runtime, the uniqueness check. All other ways to read/write a reference count are either restricted to pure swift code or if they are allowed in C++ code write to reference counts. If we were able to say that it is undefined behavior to invoke isUniquelyReferenced from non-swift runtime functions, we immediately could get nice speed boosts when using imported c code that is pure without any further work on the maintainers part.

Proposal

State that is is undefined behavior to reference isUniquelyReferenced in a non-swift function in 3rd party libraries.

*NOTE* I am talking about the "c" attribute for pure, not the "swift" attribute (whatever that ends up being eventually).

···

On Feb 2, 2016, at 1:03 PM, Michael Gottesman via swift-dev <swift-dev@swift.org> wrote:

Thoughts?
Michael
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


(David Sweeris) #3

Speedups are Very Good, but IMHO undefined behavior is Very Very Bad. How hard would it be for the compiler to detect this? If so, would it be possible to throw a warning or something and revert to the slower path if someone calls isUniquelyReferenced?

···

On Feb 2, 2016, at 13:03, Michael Gottesman via swift-dev <swift-dev@swift.org> wrote:

Background

I have recently been thinking about clang attributes and how we can take advantage of the work other people have done in terms of putting attributes in their headers especially in terms of ARC.

The two most pervasive such attributes are the const/pure attributes. Trivially the const attribute (since it can not read global memory) can not read or write reference counts. But what about pure? For those who are unfamiliar pure in "c" means that a function's value is only dependent on its arguments and reading global memory. Being able to only read global memory is an interesting property from the ARC perspective since there is only one ARC function that reads a reference count that is exported from the runtime, the uniqueness check. All other ways to read/write a reference count are either restricted to pure swift code or if they are allowed in C++ code write to reference counts. If we were able to say that it is undefined behavior to invoke isUniquelyReferenced from non-swift runtime functions, we immediately could get nice speed boosts when using imported c code that is pure without any further work on the maintainers part.

Proposal

State that is is undefined behavior to reference isUniquelyReferenced in a non-swift function in 3rd party libraries.

Thoughts?
Michael
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


(Michael Gottesman) #4

Jordan and I have ben arguing about this over IM a little bit and reached a satisfactory solution. Additionally, turns out we are already doing this (I am not sure if the uniqueness check aspect was thought about).

Anyways, I am just going to close the discussion.

Michael

···

On Feb 2, 2016, at 1:09 PM, Michael Gottesman <mgottesman@apple.com> wrote:

On Feb 2, 2016, at 1:03 PM, Michael Gottesman via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

Background

I have recently been thinking about clang attributes and how we can take advantage of the work other people have done in terms of putting attributes in their headers especially in terms of ARC.

The two most pervasive such attributes are the const/pure attributes. Trivially the const attribute (since it can not read global memory) can not read or write reference counts. But what about pure? For those who are unfamiliar pure in "c" means that a function's value is only dependent on its arguments and reading global memory. Being able to only read global memory is an interesting property from the ARC perspective since there is only one ARC function that reads a reference count that is exported from the runtime, the uniqueness check. All other ways to read/write a reference count are either restricted to pure swift code or if they are allowed in C++ code write to reference counts. If we were able to say that it is undefined behavior to invoke isUniquelyReferenced from non-swift runtime functions, we immediately could get nice speed boosts when using imported c code that is pure without any further work on the maintainers part.

Proposal

State that is is undefined behavior to reference isUniquelyReferenced in a non-swift function in 3rd party libraries.

*NOTE* I am talking about the "c" attribute for pure, not the "swift" attribute (whatever that ends up being eventually).

Thoughts?
Michael
_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev


(David Sweeris) #5

Ha, oops, I should’ve checked before sending my other reply.

···

On Feb 2, 2016, at 15:23, Michael Gottesman via swift-dev <swift-dev@swift.org> wrote:

Jordan and I have ben arguing about this over IM a little bit and reached a satisfactory solution. Additionally, turns out we are already doing this (I am not sure if the uniqueness check aspect was thought about).

Anyways, I am just going to close the discussion.

Michael

On Feb 2, 2016, at 1:09 PM, Michael Gottesman <mgottesman@apple.com <mailto:mgottesman@apple.com>> wrote:

On Feb 2, 2016, at 1:03 PM, Michael Gottesman via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

Background

I have recently been thinking about clang attributes and how we can take advantage of the work other people have done in terms of putting attributes in their headers especially in terms of ARC.

The two most pervasive such attributes are the const/pure attributes. Trivially the const attribute (since it can not read global memory) can not read or write reference counts. But what about pure? For those who are unfamiliar pure in "c" means that a function's value is only dependent on its arguments and reading global memory. Being able to only read global memory is an interesting property from the ARC perspective since there is only one ARC function that reads a reference count that is exported from the runtime, the uniqueness check. All other ways to read/write a reference count are either restricted to pure swift code or if they are allowed in C++ code write to reference counts. If we were able to say that it is undefined behavior to invoke isUniquelyReferenced from non-swift runtime functions, we immediately could get nice speed boosts when using imported c code that is pure without any further work on the maintainers part.

Proposal

State that is is undefined behavior to reference isUniquelyReferenced in a non-swift function in 3rd party libraries.

*NOTE* I am talking about the "c" attribute for pure, not the "swift" attribute (whatever that ends up being eventually).

Thoughts?
Michael
_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev

_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev


(Michael Gottesman) #6

Jordan and I have ben arguing about this over IM a little bit and reached a satisfactory solution. Additionally, turns out we are already doing this (I am not sure if the uniqueness check aspect was thought about).

To be clear, what I was referring to was that we are treating read only functions as not touching reference counts. Nothing more than that.

···

On Feb 2, 2016, at 3:23 PM, Michael Gottesman <mgottesman@apple.com> wrote:

Anyways, I am just going to close the discussion.

Michael

On Feb 2, 2016, at 1:09 PM, Michael Gottesman <mgottesman@apple.com <mailto:mgottesman@apple.com>> wrote:

On Feb 2, 2016, at 1:03 PM, Michael Gottesman via swift-dev <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:

Background

I have recently been thinking about clang attributes and how we can take advantage of the work other people have done in terms of putting attributes in their headers especially in terms of ARC.

The two most pervasive such attributes are the const/pure attributes. Trivially the const attribute (since it can not read global memory) can not read or write reference counts. But what about pure? For those who are unfamiliar pure in "c" means that a function's value is only dependent on its arguments and reading global memory. Being able to only read global memory is an interesting property from the ARC perspective since there is only one ARC function that reads a reference count that is exported from the runtime, the uniqueness check. All other ways to read/write a reference count are either restricted to pure swift code or if they are allowed in C++ code write to reference counts. If we were able to say that it is undefined behavior to invoke isUniquelyReferenced from non-swift runtime functions, we immediately could get nice speed boosts when using imported c code that is pure without any further work on the maintainers part.

Proposal

State that is is undefined behavior to reference isUniquelyReferenced in a non-swift function in 3rd party libraries.

*NOTE* I am talking about the "c" attribute for pure, not the "swift" attribute (whatever that ends up being eventually).

Thoughts?
Michael
_______________________________________________
swift-dev mailing list
swift-dev@swift.org <mailto:swift-dev@swift.org>
https://lists.swift.org/mailman/listinfo/swift-dev