On 06/07/2011 16:31, Max Bolingbroke wrote:
On 6 July 2011 16:28, Max Bolingbroke<[email protected]> wrote:
On 6 July 2011 15:44, Simon Marlow<[email protected]> wrote:
Ah, sorry I didn't read your message carefully enough.
Now I'm not sure whether this will work as is. As seen from another module,
this Id will look like a constructor, so we might pointer-tag it when
referring to it.
I'm not sure whether we actually do this or not, and it's
hard to tell from looking at the code. Pointer-tagging it would be wrong if
it were an indirection rather than an actual constructor.
Oh, you can't pointer tag indirections?
(Sorry for double email, curiosity overcame me about this point:)
Is it possible to explain why you can't pointer tag indirections? It
seems to me that this ought to be safe in the case that they are
indirections to nullary constructors:
1. If we make a decision about which case branch to go down based on
the tag bits, that is OK. We will not have made a wrong choice about
the branch to take.
2. A nullary constructor does not have any fields, so we will never
attempt to index directly into the payload of a closure we detect is
evaluated by looking at the pointer tag. If we did this for
non-nullary constructors it might be a problem because this would
result in indexing into the payload of the *indirection* rather than
the constructor itself.
So what goes wrong?
When the data type has more constructors than we have room for in the
tag bits, then the code for the alternatives will grab the tag from the
info table. If the info table is IND_STATIC_info, this will go wrong.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
