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

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

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 wrote:

Yes, in particular if the offset is zero. Morally, however, we're just doing this to clear the tag bit.

Edward

...

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@microsoft.com> wrote:

...

I’m all for it!

I believe that ByteOff/WordOff are always 0 or positive. At least,

Excerpts from Johan Tibell's message of 2014-08-07 14:45:43 +0100: 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

Hmm, surely these are used for negative offsets a lot? All Hp-relative indices are negative (but virtual Hp offsets are positive), and Sp-relative indices can be both negative and positive. On 07/08/2014 12:49, 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 mailto:ezyang@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

On 07/08/14 15:45, Simon Peyton Jones wrote:

When I introduced them in the first place they were used for positive offsets within StackAreas and heap objects. Both are organised with the zeroth byte of the stack area or heap object being at the lowest address.

It's true that a positive offset from the beginning of a block of contiguous freshly-allocated heap objects will turn into a negative displacement from the actual, physical heap pointer. If ByteOff is used for both purpose then yes there will be negative ones.

More than that I cannot say. They may well be being used for other purposes by now.

I'm hazy on the history but I'm sure you're right. In any case I'm pretty sure I've used these types in lots of places.

One thought is that the profiling word appears just *before* the start of a heap object, so that might need a negative offset, but it seems like a rather special case.

Hmmm... the profiling word is the second word of the object, after the info pointer. Cheers, Simon

Simon

| -----Original Message----- | From: Simon Marlow [mailto:marlowsd@gmail.com] | Sent: 07 August 2014 15:26 | To: Simon Peyton Jones; Johan Tibell | Cc: ghc-devs@haskell.org | Subject: Re: Improving the Int/Word story inside GHC | | Hmm, surely these are used for negative offsets a lot? All Hp-relative | indices are negative (but virtual Hp offsets are positive), and Sp- | relative indices can be both negative and positive. | | On 07/08/2014 12:49, 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 mailto:ezyang@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 | >

would this result in evolving how vector/array indexing works internally to using Words rather than Ints? On Thu, Aug 7, 2014 at 5:37 PM, Simon Peyton Jones wrote:

| > One thought is that the profiling word appears just *before* the start | of a heap object, so that might need a negative offset, but it seems like | a rather special case. | | Hmmm... the profiling word is the second word of the object, after the | info pointer.

Oh, OK, I'm mis-remembering that; apols.

Simon _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

On Thu, Aug 7, 2014 at 4:36 PM, Simon Marlow wrote:

I think doing the comparison with Integer is the right fix. Relying on Word being big enough for these things is technically wrong because we might be cross-compiling from a smaller word size.

That sounds like an easier fix and I will try that. Unfortunately working with Integers means lots of our convenience functions, such as wordsToBytes, go out the window, as the all work on Byte/WordOff. Here's an example that now gets more annoying: shouldInlinePrimOp dflags NewArrayOp [(CmmLit (CmmInt n _)), init] | wordsToBytes dflags (fromInteger n) <= maxInlineAllocSize dflags = Most of our array primops are likely* still wrong, as the code that generates them uses Int everywhere. Still also sounds like a problem for cross-compiling. * In some cases we might be lucky and the Int is never introspected any we just look at the bits (i.e. pretend it's a Word) when we generate code.