Improving the Int/Word story inside GHC

[Johan Tibell]

I've uploaded https://phabricator.haskell.org/D125 to give an idea of what
such a change might look like. I'm not quite done with the change (it's
quite a chore) but the commit gives and idea of what such a change might
look like.

I'm still not convinced that making ByteOff a Word is the right thing,
there seems to be several cases where it's used to represent a negative
offset.


On Thu, Aug 7, 2014 at 3:53 PM, Johan Tibell <johan.tibell at gmail.com> wrote:

> I guess this example, from mk_switch in StgCmmUtils, is the same
>
>     return (mkSwitch (cmmOffset dflags tag_expr (- real_lo_tag)) arms)
>
> ?
>
> (This is clearly a negative offset and I don't know the implications of
> the Cmm code we output if we switch to ByteOff = Word)
>
>
> On Thu, Aug 7, 2014 at 3:49 PM, Edward Z. Yang <ezyang at mit.edu> wrote:
>
>> Yes, in particular if the offset is zero.  Morally, however, we're
>> just doing this to clear the tag bit.
>>
>> Edward
>>
>> Excerpts from Johan Tibell's message of 2014-08-07 14:45:43 +0100:
>> > I'm hacking on this now. I'm not 100% sure that ByteOff isn't used for
>> > negative values though, see for example
>> >
>> > mkTaggedObjectLoad
>> >   :: DynFlags -> LocalReg -> LocalReg -> ByteOff -> DynTag -> CmmAGraph
>> > -- (loadTaggedObjectField reg base off tag) generates assignment
>> > --      reg = bitsK[ base + off - tag ]
>> > -- where K is fixed by 'reg'
>> > mkTaggedObjectLoad dflags reg base offset tag
>> >   = mkAssign (CmmLocal reg)
>> >              (CmmLoad (cmmOffsetB dflags
>> >                                   (CmmReg (CmmLocal base))
>> >                                   (offset - tag))
>> >                       (localRegType reg))
>> >
>> > from StgCmmUtils.
>> >
>> > Wouldn't it be possible that the offset in cmmOffsetB (which is of type
>> > ByteOff) could be negative?
>> >
>> >
>> >
>> > On Thu, Aug 7, 2014 at 1:49 PM, Simon Peyton Jones <
>> simonpj at microsoft.com>
>> > wrote:
>> >
>> > >  I’m all for it!
>> > >
>> > >
>> > >
>> > > I believe that ByteOff/WordOff are always 0 or positive.   At least,
>> they
>> > > were when I introduced them!
>> > >
>> > >
>> > >
>> > > SImon
>> > >
>> > >
>> > >
>> > > *From:* ghc-devs [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of
>> *Johan
>> > > Tibell
>> > > *Sent:* 07 August 2014 12:21
>> > > *To:* Simon Marlow
>> > > *Cc:* ghc-devs at haskell.org
>> > > *Subject:* Re: Improving the Int/Word story inside GHC
>> > >
>> > >
>> > >
>> > > Simon M, is the intention of ByteOff and WordOff that they should be
>> able
>> > > to represent negative quantities as well? If so we might need to
>> split it
>> > > into ByteOff (still an Int) and ByteIndex (a Word) to have a type for
>> > > indexing into arrays.
>> > >
>> > >
>> > >
>> > > On Thu, Aug 7, 2014 at 1:16 PM, Edward Z. Yang <ezyang at mit.edu>
>> wrote:
>> > >
>> > >  If it's strictly just in the codegen (and not affecting user code),
>> > > seems fine to me.
>> > >
>> > > Edward
>> > >
>> > > Excerpts from Johan Tibell's message of 2014-08-07 12:10:37 +0100:
>> > >
>> > > > Inside GHC we mostly use Int instead of Word, even when we want to
>> > > > represent non-negative values, such as sizes of things or indices
>> into
>> > > > things. This is now causing some grief in
>> > > > https://ghc.haskell.org/trac/ghc/ticket/9416, where an allocation
>> > > boundary
>> > > > case test fails with a segfault because a n < m Int comparison
>> overflows.
>> > > >
>> > > > I tried to fix the issue by changing the type of maxInlineAllocSize,
>> > > which
>> > > > is used on one side of the above comparison, to Word. However, that
>> > > > unravels a bunch of other issues, such as wordsToBytes, ByteOff,
>> etc are
>> > > > all Int-valued quantities.
>> > > >
>> > > > I could perhaps work around these problems by judicious use of
>> > > fromIntegral
>> > > > in StgCmmPrim, but I'm a bit unhappy about it because it 1) makes
>> the
>> > > code
>> > > > uglier and 2) needs to be done in quite a few places.
>> > > >
>> > > > How much work would it be to try to switch the codegen to use Word
>> for
>> > > most
>> > > > of these quantities instead?
>> > > >
>> > > > -- Johan
>> > >
>> > >
>> > >
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140807/c9e74f57/attachment-0001.html>