Give -fexpose-all-unfoldings the same semantics as INLINABLE on each function

Feature request: give -fexpose-all-unfoldings the same semantics as INLINABLE on each function.

For simplicity, for the principle of least surprise and for usability of-fexpose-all-unfoldings, so that it can actually replace tons of INLINABLE that are needed, e.g., for code with lots of abstract class constraints to force it to specialize to the single class that is actually used.

Trac metadata

Trac field	Value
Version	8.0.1
Type	FeatureRequest
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related	#12962 (closed)
Blocking
CC
Operating system
Architecture

mentioned in issue #12463

mentioned in issue #12962 (closed)

changed weight to 5

added Tfeature request Trac import labels

I should mention that the semantics of -fexpose-all-unfoldings is currently different from INLINABLE on each function. In particular, it produces much slower programs for my codebase, probably because it doesn't force specialization (though it makes it possible by exposing the unfoldings), as opposed to INLINABLE.

This is very vague. You say that the semantics are different but how have you observed this? INLINABLE doesn't do anything about "forcing specialisation" so I'm unclear what you mean. If I was to guess I would say that -fexpose-all-unfoldings exposes optimised unfoldings rather than unoptimised unfoldings like INLINABLE.

Now to make progress, do you have a small code sample which behaves differently with INLINABLE vs -fexpose-all-unfoldings?

Yes, I'm being lazy. I've only benchmarked my big codebase (https://github.com/LambdaHack/LambdaHack). It may not be easy to find a small example in which GHC nevertheless fails to specialize a function for which it has an available unfolding.

I got the bit about INLINABLE forcing specialization from here: #12463##12963 (closed)

Trac metadata

Trac field	Value
Related	#12962 (closed) → #12463, #12962 (closed)

Feature request: give -fexpose-all-unfoldings the same semantics as INLINABLE on each function.

I don't think we should do this.

• -fexpose-all-unfoldings has no effect on the optimisation pipeline; it just arranges that, at the end of the pipeline all the unfoldings for all functions are put into the interface file.
• INLINABLE is quite different. It says to snapshot (essentially the source code of) the RHS of the function, and make it available for inlining and/or specialisation at call sites. So it could have a major effect on the optimisation pipeline. (I'd prefer that it was called SPECIALISABLE.)

Anyway I don't think it'd be a good idea to make them the same. If you want all the user-written top-level functions to be INLINABLE, we'll need a way to say just that; a reasonable feature request. Perhaps {-# SPECIALISABLE_ALL #-}?

closed

Oh, I didn't know the difference between -fexpose-all-unfoldings and giving all functions INLINABLE is so big and so well defined. Given that, I drop this feature request in favour of #12463. RECURSIVE_SPECIALISABLE fits my use case even better and in the worst case the proposal may reduce to something similar to SPECIALISABLE_ALL, so I will focus there. Thank you, Simon! Thank you, mpickering! Closing.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedDuplicate

added Pnormal label