Re: Improving the Int/Word story inside GHC

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 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@haskell.org] *On Behalf Of *Johan Tibell *Sent:* 07 August 2014 12:21 *To:* Simon Marlow *Cc:* ghc-devs@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 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