Opened 14 months ago

Last modified 4 months ago

#15454 new feature request

Have GHCi automatically use -fobject-code for modules that use UnboxedTuples

Reported by: mgsloan Owned by:
Priority: normal Milestone: 8.10.1
Component: Compiler Version: 8.4.3
Keywords: Cc:
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

This is related to a relatively old issue, that the bytecode interpreter cannot handle UnboxedTuples: https://ghc.haskell.org/trac/ghc/ticket/1257 . Rather than fix that issue, which sounds quite challenging, how about adding some automagic to GHCi which builds object code for modules that use UnboxedTuples?

This is a bit trickier than just compiling those modules to object code, because object code cannot be linked against byte code (see https://ghc.haskell.org/trac/ghc/ticket/10965). A potential solution to this is to also build all of the dependencies of modules that use UnboxedTuples using object code.

This idea has some precedent, though as an external script - see https://ghc.haskell.org/trac/ghc/ticket/13101 and https://gist.github.com/bgamari/bd53e4fd6f3323599387ffc7b11d1a1e . I think it would be best to put the solution to this directly in GHCi. What do you think? If y'all think it is a good idea, then I can volunteer to try to make it happen.

As described in that ticket, this would be particularly helpful for loading GHC into GHCi, because GHC's code uses UnboxedTuples. Currently, -fobject-code must be used, which means that the speedup from using GHCi isn't quite as much as it could be. It is possible to get around this by first loading it with object code and then doing another load without object code, but that's rather inconvenient.

Since this may be a surprising behavior change (the user may not have specified -odir and -hidir), it could possibly be enabled via a flag.

Change History (6)

comment:1 Changed 14 months ago by bgamari

Milestone: 8.6.18.8.1

These won't be fixed for in GHC 8.6.

comment:2 Changed 9 months ago by osa1

Milestone: 8.8.18.10.1

Bumping milestones of low-priority tickets.

comment:3 Changed 6 months ago by Marge Bot <ben+marge-bot@…>

In c01d5af3/ghc:

Extract out use of UnboxedTuples from GHCi.Leak

See #13101 + #15454 for motivation.  This change reduces the number of
modules that need to be compiled to object code when loading GHC into
GHCi.

comment:4 Changed 6 months ago by Marge Bot <ben+marge-bot@…>

In 061276ea/ghc:

Remove unnecessary uses of UnboxedTuples pragma (see #13101 / #15454)

Also removes a couple unnecessary MagicHash pragmas

comment:5 Changed 4 months ago by Marge Bot <ben+marge-bot@…>

In 21272670/ghc:

Have GHCi use object code for UnboxedTuples modules #15454

The idea is to automatically enable -fobject-code for modules that use
UnboxedTuples, along with all the modules they depend on. When looking
into how to solve this, I was pleased to find that there was already
highly similar logic for enabling code generation when -fno-code is
specified but TemplateHaskell is used.

The state before this patch was that if you used unboxed tuples then you
had to enable `-fobject-code` globally rather than on a per module
basis.

comment:6 Changed 4 months ago by Marge Bot <ben+marge-bot@…>

In ddae344/ghc:

Use datatype for unboxed returns when loading ghc into ghci

See #13101 and #15454
Note: See TracTickets for help on using tickets.