Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix inling of _apply(_apply, ...) #29622

Merged
merged 1 commit into from
Oct 16, 2018
Merged

Fix inling of _apply(_apply, ...) #29622

merged 1 commit into from
Oct 16, 2018

Conversation

Keno
Copy link
Member

@Keno Keno commented Oct 13, 2018

Cassette and packages that work similarly (e.g. Zygote) perform
some variant of the following transformation
For f(a,b,c) = g(a,b,c), they define

(::overloaded{f})(c::Context, f, args...) = _apply(overloaded{g}(), (c, g), args)

With all of our recent compiler improvements inference can now handle
this pattern fairly well. However, inlining was falling over for the
case where g === _apply (because it didn't check the _apply special
case again after inlining the first _apply), causing inefficiencies
(_apply is fairly expensive). Fix that by revisiting the _apply check.
While we're at it, also remove the obsolete isapply flag in InliningTodo,
since we now do all the rewriting up front.

cc @jrevels @MikeInnes

Copy link
Member Author

@Keno Keno left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is broken

Cassette and packages that work similarly (e.g. Zygote) perform
essentially the following transformation:

For `f(args...) = g(args...)`, they define

```
(::overloaded{f})(c::Context, f, args...) = _apply(overloaded{g}(), (c, g), args)
```

With all of our recent compiler improvements inference can now handle
this pattern fairly well. However, inlining was falling over for the
case where `g === _apply` (because it didn't check the _apply special
case again after inlining the first _apply), causing inefficiencies
(_apply is fairly expensive). Fix that by revisiting the _apply check.
While we're at it, also remove the obsolete isapply flag in InliningTodo,
since we now do all the rewriting up front.
@Keno Keno force-pushed the kf/applyinlining branch from 00243c3 to 75f512b Compare October 15, 2018 04:39
@Keno
Copy link
Member Author

Keno commented Oct 15, 2018

Fixed

@Keno
Copy link
Member Author

Keno commented Oct 15, 2018

@nanosoldier runbenchmarks(ALL, vs=":master")

@nanosoldier
Copy link
Collaborator

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here. cc @ararslan

@Keno
Copy link
Member Author

Keno commented Oct 16, 2018

Bit of a mixed nanosolider bag, but I spot checked some of them (the sqrt ones claiming >2x slowdown in particular), and I don't see any difference locally. Merging. I'll keep an eye on the nightly benchmark though.

@Keno Keno merged commit ca5fa12 into master Oct 16, 2018
@KristofferC KristofferC deleted the kf/applyinlining branch October 16, 2018 01:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants