Opened 10 years ago

Closed 6 years ago

Last modified 13 months ago

#1257 closed bug (wontfix)

Bytecode generator can't handle unboxed tuples

Reported by: igloo Owned by:
Priority: high Milestone: 7.4.1
Component: GHCi Version: 6.6
Keywords: Cc: michal.terepeta@…, hvr, rodlogic
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case: dsrun014
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

We need to implement unboxed tuple support in ghci.

For example, with:

f :: a -> b -> (# a, b #)
f x y = (# x, y #)

we get:

$ ghci -v0 -fglasgow-exts w.hs
ghc-6.6: panic! (the 'impossible' happened)
  (GHC version 6.6 for x86_64-unknown-linux):
        Bytecode generator can't handle unboxed tuples.  Possibly due
        to foreign import/export decls in source.  Workaround:
        compile this module to a .o file, then restart session.

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

Change History (12)

comment:1 Changed 10 years ago by simonmar

Owner: set to simonmar

IIRC, it's not really feasible to do this in general. I'll investigate before 6.8 anyway.

comment:2 Changed 10 years ago by simonmar

Milestone: 6.8 branch_|_
Owner: simonmar deleted

This isn't going to happen, mainly because there are an infinite family of return conventions for unboxed tuples. We could cover more cases without too much difficulty, but the general case is really hard. Given that you can now do -fobject-code, it doesn't really seem worth it.

comment:3 Changed 9 years ago by simonmar

Architecture: UnknownUnknown/Multiple

comment:4 Changed 9 years ago by simonmar

Operating System: UnknownUnknown/Multiple

comment:5 Changed 7 years ago by michalt

Cc: michal.terepeta@… added
Status: newinfoneeded
Type of failure: None/Unknown

I've just tried to load a file with the above example and ghci just printed a nice error message:

[1 of 1] Compiling Test             ( Test.hs, interpreted )
Error: bytecode compiler can't handle unboxed tuples.
  Possibly due to foreign import/export decls in source.
  Workaround: use -fobject-code, or compile this module to .o separately.
>

So if it is difficult to implement and one can use -fobject-code then maybe we should just close the ticket?

comment:6 in reply to:  5 Changed 7 years ago by simonmar

Replying to michalt:

So if it is difficult to implement and one can use -fobject-code then maybe we should just close the ticket?

That's what the _|_ milestone is for: bugs that either we can't fix, or aren't important enough to fix.

In this case, wouldn't it be better if GHC just automatically switched on -fobject-code?

comment:7 Changed 6 years ago by igloo

Milestone: _|_7.4.1
Priority: normalhigh
Status: infoneedednew

Let's either automatically enable -fobject-code, or add a suggestion to turn it on to the error message, and then close this ticket as wontfix.

comment:8 Changed 6 years ago by igloo

Resolution: wontfix
Status: newclosed

Oh, the error already suggests -fobject-code.

I'm not a fan of magic like turning -fobject-code on automatically, so let's just mark this wontfix.

comment:9 Changed 3 years ago by rodlogic

Cc: hvr added

Could someone expand a bit on why there are infinite family of return conventions for unboxed tuples? And possibly how could this restriction be lifted?

comment:10 Changed 3 years ago by rodlogic

Cc: rodlogic added

comment:11 Changed 3 years ago by simonmar

The problem is at the boundary between compiled code and interpreted code. We have a few special-purpose stack frames that do the impedence matching between the two worlds, one for each return convention. The problem with unboxed tuples is that there aren't a fixed number of return conventions, so we can't cover all the cases with a few stack frames.

I haven't thought about this for a long time, but perhaps there's a way to make a generic stack frame that takes some kind of descriptor to describe the convention.

Last edited 3 years ago by simonmar (previous) (diff)

comment:12 Changed 13 months ago by dobenour

I can think of a few options

  • Auto-generate a bunch of return frames for different length tuples. Doesn't work because unboxed tuples can store unboxed data, so we get an exponential code size blowup.
  • Write a little interpreter (directly in Cmm) that looks at metadata in stack frame and does the appropriate operations. This one should work.
Note: See TracTickets for help on using tickets.