Get rid of specialized pullback generation for semantic member accessors

[asl]

Currently there is a special path for semantic member accessors pullback generation (getters and setters). Maybe I am missing something, but this should not be required at all and generic pullback generation code should handle these functions just fine.

It did make a bit sense in the past when there was no support for inout arguments, so setters would certainly should be special-cased. I do not see any obvious reason why getters are special.

Anyway, if we'd remove the special case generation we're having few assertions failures. I believe this should be considered as as a bug, investigated and fixed. Ultimately, the generic code should handle pullback generation for semantic member accessors as-is.

[asl]

Tagging @rxwei @dan-zheng for some retrospective and generic wisdom :)

[asl]

Tagging @BradLarson @asavonic

[dan-zheng]

Thanks for the mention.

Yes, you are right that there's no reason to special case pullback generation for normal getters and setters.

---

I recall we added "semantic member accessor" pullback generation for special-case handling of property-wrapper-backed properties: https://forums.swift.org/t/differentiating-wrapped-properties/35638.

Idea

Instead, we can make Differentiable conformance derivation treat wrapped stored properties like normal stored properties, using them to compute tangent properties in TangentVector. This makes behavior consistent for normal stored properties and wrapped stored properties: one might say this is a fix rather than a new feature.

#31173 pull request description has details:

Differentiation transform

The differentiation transform is also updated to support differentiation of
wrapped value accessors.

This is done via a new pullback generation code path for "semantic member
accessors". "Semantic member accessors" are accessors attached to member
properties that have a corresponding tangent stored property in the parent
TangentVector type.

These accessors have special-case pullback generation based on their semantic
behavior. Currently, only getters and setters are supported.

This special-case pullback generation is currently used for stored property
accessors and property wrapper wrapped value accessors. In the future, it can
also be used to support @differentiable(useInTangentVector) computed
properties: SR-12636.

User-defined accesors cannot use this code path because they may use custom
logic that does not semantically perform a member access.

Maybe you or @rxwei would have thoughts on whether "wrapped stored property" differentiation is still relevant.

[dan-zheng]

One other reason for "semantic member accessor" special-casing: it would allow us to support _modify accessor differentiation in a special-case way without full support for coroutine differentiation.

https://github.com/apple/swift/blob/9e73dad31110312356469364ba314603d8cff4b7/lib/SILOptimizer/Differentiation/PullbackCloner.cpp#L2623-L2636

Maybe you or others have context on whether this is still relevant :)

[asl]

Thanks @dan-zheng for the insights. This was really helpful. Actually, the question happened in the context of class differentiation (and modify accessors is one subtask here, it is important at least to support Array subscripts) as it would require to to special case even more and I found that ordinary pullback generation code worked just nice for the normal getters / setters here.

I will need to think a little bit about wrapped value accessors. Maybe we'd just "special case" less.

[asl]

@dan-zheng So, currently we're doing special cases for stored properties (https://github.com/apple/swift/blob/main/lib/SILOptimizer/Differentiation/Common.cpp#L83) and wrapped ones (https://github.com/apple/swift/blob/main/lib/SILOptimizer/Differentiation/Common.cpp#L86)

It looks like we can keep the special case only for wrapped ones (as we'd need to access the underlying unwrapped field as written in your proposal), but remove the other, generic case. All tests do pass in such case. Anything else I might be missing?

I do not think that special casing will help with _modify accessors as "interesting" cases are user-provided (https://github.com/apple/swift/blob/main/stdlib/public/core/Array.swift#L751)

[dan-zheng]

Nice! Sounds good to me, though I'm not an active code owner.

[asl]

Yeah. I'm just doing some code archaeology to ensure we are not missing something important which there are no testcases for or other code references :) So, some past knowledge is very helpful and saves lots of time. Thanks!