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
