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.tib...@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 <ezy...@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 < >> simo...@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-boun...@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 <ezy...@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 >> > > >> > > >> > > >> > >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs