RULES that never fire (automatically)

[andygill]

We want a way of having GHC RULES known by GHC, but not used by the optimizer.

HERMIT, a interactive plugin for GHC that applies rules - and as well as built in rules (like alpha conversion, beta-reduction, etc) - also provide access to the named GHC RULES. Here is the rub: We want to use GHC RULES that are parsed and typed checked like normal rules, are visible to the HERMIT system, but never run by the simplifier. Currently we can say

• attempt this before this (opt) pass, or
• attempt after this pass,

but there is no way of saying

• never attempt.

We were thinking

    {-# RULES [~] "map/map" forall f g . map f (map g xs) = map (f.g) xs #-}

Where the [~] says *never* execute this without be explicitly asked, following on from the [~0] which does not run in first pass.

We are happy making the required changes.

[simonpj]

I think I'm ok with this. All the machinery is there already except for the concrete syntax to say "never execute".

The only question in my mind is whether to be a bit more explicit by saying

  {-# RULES [NEVER] "map/map" ... #-}

but that means more work in the lexer, so it probably isn't worth it. I don't feel strongly.

Simon

[afarmer]

Patch to parser to support specifying RULES that never automatically fire

[afarmer]

test for 7162

[afarmer]

Here is a patch that implements this functionality (with [~] meaning never automatically fire), as well as a patch to the testsuite to verify the parser works.

I've built HERMIT against head (with this patch applied) and verified that we can still use RULES that are marked to never fire (at both ends of the optimization pipeline). As an aside, all the packages required by HERMIT compiled fine, so it doesn't seem to break any existing code. I've also run the ghc validate script, with no extra unexpected errors.

[igloo]

Thanks for the patch. We'll take a look.

[afarmer]

I think Andy had originally hoped that this would make it into 7.6.2.

Is that still possible? It's a very small change.

[igloo]

We have a policy of not making interface changes in stable branches, sorry

[afarmer@…]

commit 779f10fdedbeeb31891f3f3772cbc2dfdd32e1ee

Author: Andrew Farmer <afarmer@ittc.ku.edu>
Date:   Thu Oct 4 16:51:28 2012 -0500

    Extend parser to allow specification of RULES that never fire. #7162

 compiler/parser/Parser.y.pp |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

[igloo]

Applied thanks - and thanks for the test too!

[simonpj]

Whoa! Where's the documentation? Andrew, can you send a patch to the user manual, please?

Simon

[afarmer]

So while documenting this, I realized this patch makes an unintended change. Namely, the INLINE pragma uses the same parser rules for activation as the RULES pragma. So it is now possible to write:

{-# INLINE [~] ... #-} and {-# NOINLINE [~] ... #-}

Looking at RdrHsSyn?.lhs, the first case (INLINE [~]) is equivalent to NOINLINE. Worryingly, I have yet to figure out how the second case (NOINLINE [~]) behaves.

So as I see it, there are two possible solutions.

1. I submit a new patch to the parser that separates the activation parsing for RULES and INLINE so RULES [~] is possible but INLINE [~] is not.

2. I figure out what NOINLINE [~] means and document that.

Opinions? I'm inclined towards option 1, as I think it'll be less confusing for the user.

[simonpj]

Yes (1) looks best to me. Alternatively, you could make [~] parse as an activation but check in INLINE and SPECIALISE productions that it didn't come back as NeverActive.

Regardless, please add comments in the parser to explain what is going on.

[afarmer]

Fix parser to only parse the [~] for RULES pragmas (not INLINE etc)

[afarmer]

Move 7162 test to proper directory, add test to make sure INLINE [~] doesn't parse.

[afarmer]

Here are two patches that implement option 1. This includes a note in the user's guide about [~] on RULES.

[simonpj]

OK I've pushed this

commit c56c355b0f5504f8afd062ca4c78a8bb40905299
Author: Andrew Farmer <afarmer@ittc.ku.edu>
Date:   Thu Dec 6 15:47:33 2012 -0600

    Only allow special NeverActive syntax for RULES.

 compiler/parser/Parser.y.pp       |   17 +++++++++++++----
 docs/users_guide/glasgow_exts.xml |    3 +++
 2 files changed, 16 insertions(+), 4 deletions(-)

plus an extra sentence in the docs

commit d3e2912ac2048346828539e0dfef6c0cefef0d38
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date:   Fri Dec 21 13:17:26 2012 +0000

    Clarify documentation of [~] syntax on RULE activations

 docs/users_guide/glasgow_exts.xml |    3 +++
 1 file changed, 3 insertions(+)