CORE notes break optimisation

[rl]

I think at some point we decided that Core notes shouldn't affect optimisation. Here is a case where they do:

module Foo where

foo :: Int -> Int
{-# INLINE [1] foo #-}
foo x = x+1

{-# RULES "foo/foo" forall x. foo (foo x) = x #-}

module Bar where

import Foo

bar :: Int -> Int -> Int
bar x y = foo ({-# CORE "note" #-} x `seq` foo y)

When compiled with -O2, the rule doesn't fire with the note but does fire without it. This is the Core with the note:

Bar.bar =
  \ (x_aaw :: GHC.Types.Int) (y_aax :: GHC.Types.Int) ->
    Foo.foo
      (__core_note "note"
       (case x_aaw of _ { GHC.Types.I# _ -> Foo.foo y_aax }))

For the rule to fire, GHC must move the seq to the outside but because of the note, it doesn't.

[simonpj]

I didn't konw anyone was using core notes. Are you using them in DPH? Why? Depending on their semantics the above "move the seq" might or might not be correct.

[rl]

I don't use them, a vector user ran into this. It's just that I think we said they shouldn't affect optimisation (in particular, we made the rule matcher look through them) so I wanted to record this.

[choenerzs]

I am that user ;-)

They are very good for finding out if some piece of code is being correctly optimized -- if CORE notes don't interfere with optimization. Right now I just tag the outermost layer of code instead of smaller pieces, but they were very helpful in some cases.

[simonpj]

I'm really not sure what to do here. If we move the seq to the outside, we'd presumably need to move the note, which in turn might break whatever the user had in mind for the semantics of his notes.

I propose to do nothing, but I'll leave the ticket open with a milestone of bottom, just as a vague reminder that we don't really know what notes do.

Simon