Opened 3 years ago

Last modified 3 months ago

#12178 new feature request

Allow inline pragmas on pattern synonyms

Reported by: mpickering Owned by:
Priority: high Milestone: 8.8.1
Component: Compiler Version: 8.0.1
Keywords: PatternSynonyms, newcomer Cc: bgamari, edsko
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

Richard observes that it might be useful to allow inline pragmas to refer to pattern synonyms to ensure that the matcher is inlined.

The main question to resolve is whether {-# INLINE P #-} means to inline just the matcher, just the builder or both. It seems that without more fine grained control then the pragma should cause both the matcher and builder to be inline but I am not certain about this.

Change History (11)

comment:1 Changed 2 years ago by edsko

Cc: edsko added

comment:2 Changed 2 years ago by bgamari

Cc: bgamari added
Priority: normalhigh

Bumping the importance of this since you really should be able to use pattern synonyms in a manner without compromising performance.

Moreover, I wonder whether builders and matchers should be given a bit of a discount for their inlining cost, reflecting the user's likely intuition that patterns synonyms are generally cheap and small.

I agree that a simple INLINE P pragma should inline both the matcher and the builder of P. Indeed we could expose INLINE_MATCHER and INLINE_BUILDER variants as well, although I am doubtful that they would pull their weight.

Last edited 2 years ago by bgamari (previous) (diff)

comment:3 Changed 2 years ago by goldfire

I hate to say it, but I feel confident someone will want the finer control here. But I suppose there would be no barrier to implementing the finer control later and so we should start with the simpler version.

comment:4 Changed 2 years ago by bgamari

Milestone: 8.2.1

comment:5 Changed 22 months ago by bgamari

Milestone: 8.2.18.4.1

Sadly this won't happen for 8.2.

Last edited 22 months ago by bgamari (previous) (diff)

comment:6 Changed 15 months ago by osa1

Owner: set to osa1

I have some time to work on GHC these days and I'll be working on this feature.

comment:7 Changed 11 months ago by bgamari

Keywords: newcomer added
Milestone: 8.4.18.6.1

Perhaps we'll be able to get this done for 8.6.

comment:8 Changed 6 months ago by bgamari

Milestone: 8.6.18.8.1

This won't happen for 8.8.

comment:9 Changed 3 months ago by osa1

Owner: osa1 deleted

comment:10 Changed 3 months ago by chessai

Why would a pattern synonym not get inlined by default, always? Pattern Synonyms AFAIK don't perform any computation; only computation that may occur within a Pattern Synonym would be within ViewPatterns, but inlining any function inside of the ViewPattern shouldn't matter to just the issue of inlining the Pattern Synonym. Please correct me if I am wrong or missing something.

comment:11 Changed 3 months ago by simonpj

Why would a pattern synonym not get inlined by default, always?

The only disadvantage to inlining is code size; and that applies equally to all inlining decisions, whether for pattern synonyms or any other function. Consider

pattern P a = [[[[a]]]]
f x = P (x+1)
g y = P (y-1)

Here's what it compiles to, without inlining

$bP x = (:) ((:) ((:) ((:) x []) []) []) []
f x = $bP (x+1)
g y = $bP (y-1)

Yes, we could inline $bP:

f x = (:) ((:) ((:) ((:) (x+1) []) []) []) []
g y = (:) ((:) ((:) ((:) (y-1) []) []) []) []

But really nothing much was gained by inlining the builder $bp.

It's the same for matching.

Note: See TracTickets for help on using tickets.