Opened 4 years ago

Last modified 6 months ago

#11441 new feature request

RFC: Inline intermediate languages (Core, STG, Cmm, even StrictCore)

Reported by: Iceland_jack Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.10.3
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Runtime performance bug Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

Allow intermediate code inline.

Inline Core

Typeable/WithTypeable:

withTypeable :: TTypeRep a -> (Typeable a => r) -> r

Currently, withTypeable cannot be written in Haskell, but it is straightforward to write in Core. Can we fix this?

A reflection on types (2016):

We cannot implement withTypeable in Haskell source. But we can implement it in GHC's statically-typed intermediate language, System FC. The definition is simple, roughly like this:

withTypeable tr k = k tr    -- Not quite right

Its second argument k expects a Typeable dictionary as its value argument. But since a Typeable dictionary is represented by a TypeRep, we can simply pass tr to k. When written in System FC there is a type-safe coercion to move from TypeRep a to Typeable a, but that coercion is erased at runtime. Since the definition can be statically type checked, withTypeable does not form part of the trusted code base.

Inline Cmm

Edkward Kmett writes his own .cmm hither, yon.

Inline Strict Core

Should Types are calling conventions (2009) be implemented:

4.4 The seq function

A nice feature of Strict CoreANF is that it is possible to give a straightforward definition of the primitive seq function of Haskell:

seq : {a:* -> b:* -> {a} -> {b} -> b}
 = { \a:*. \b:*. \x:{a}. \y:{b}. let _:a = x <> in y <> }

Change History (10)

comment:1 Changed 4 years ago by goldfire

I think this would be quite useful. And quite a lot of work. Are you volunteering to do it? :)

comment:2 Changed 4 years ago by thomie

Type: bugfeature request

comment:3 Changed 4 years ago by Iceland_jack

Another example of Core from ghc-devs:

It’d probably need a built-in function

setCallStack :: CallStack -> (AppendsCallStack => a) -> a

Correct. This is easy to write in Core but not in Haskell. We also need something similar for Typeable, when we get a type-indexed version of TypeRep

withTypeable :: TypeRep a -> (Typeable a => r) => r

comment:4 in reply to:  1 Changed 4 years ago by Iceland_jack

Quick coinage:

Verb

to push one's own applecart

  • (idiomatic) To strive or push for efforts that realise one's own ideas or vision.

See also


Replying to goldfire:

I think this would be quite useful. And quite a lot of work. Are you volunteering to do it? :)

If there is support for the idea I can push my own applecart (...) and take it on, but I would need feedback from those more familiar with GHC internals to begin forming the idea.

comment:5 Changed 4 years ago by Iceland_jack

Focusing on Core for now, we can reuse Haskell's syntax (some intersection between Haskell and Core syntax), see #11350, with minor sugar for functions:

{-# CORE id #-}
id :: forall a. a -> a
id @a (x :: a) = x

{-# CORE add #-}
double :: forall num. Num num => num -> num
double (@ num) (numDict :: Num num) (x :: num) =
  (+) (@ num) numDict x x

or we could cheekily reuse Template Haskell. Like this suggestions to define a magic module for implicit values we can have define a magic module of quoters (QuasiQuoters for sublanguages that are treated specially:

import GHC.Magic (core, stg)

[core|
id :: forall a. a -> a
id = \ (@ a) (x :: a) -> x

double :: forall num. Num num => num -> num
double = \(@ num) (numDict :: Num num) (x :: num) -> 
  + @ num numDict x x
|]

or a combinator library where users code directly in Core AST, data Expr b = Var Id | ....

Some questions:

  • Dictionaries and their scope.
  • Writing function metadata.
  • Only top-level definitions?
  • ...

Interested in other uses.

comment:6 Changed 4 years ago by thomie

Type of failure: None/UnknownRuntime performance bug

comment:7 Changed 4 years ago by Iceland_jack

comment:8 Changed 3 years ago by Iceland_jack

ticket:11715#comment:9 covers some of the same ground

comment:10 Changed 6 months ago by recursion-ninja

I would find this capability extremely useful for writing optimized string alignment code that is still under the purview of the GHC memory manager instead of an FFI binding to C or C++ where the memory models are disjoint and sharing is much more difficult.

Note: See TracTickets for help on using tickets.