1. 12 Jul, 2020 2 commits
    • Andreas Klebinger's avatar
      Give Uniq[D]FM a phantom type for its key. · c4de6a7a
      Andreas Klebinger authored
      This fixes #17667 and should help to avoid such issues going forward.
      The changes are mostly mechanical in nature. With two notable
      * The register allocator.
        The register allocator references registers by distinct uniques.
        However they come from the types of VirtualReg, Reg or Unique in
        various places. As a result we sometimes cast the key type of the
        map and use functions which operate on the now typed map but take
        a raw Unique as actual key. The logic itself has not changed it
        just becomes obvious where we do so now.
      * <Type>Env Modules.
      As an example a ClassEnv is currently queried using the types `Class`,
      `Name`, and `TyCon`. This is safe since for a distinct class value all
      these expressions give the same unique.
          getUnique cls
          getUnique (classTyCon cls)
          getUnique (className cls)
          getUnique (tcName $ classTyCon cls)
      This is for the most part contained within the modules defining the
      interface. However it requires us to play dirty when we are given a
      `Name` to lookup in a `UniqFM Class a` map. But again the logic did
      not change and it's for the most part hidden behind the Env Module.
      Some of these cases could be avoided by refactoring but this is left
      for future work.
      We also bump the haddock submodule as it uses UniqFM.
    • Artem Pelenitsyn's avatar
      add reproducer for #15630 · de139cc4
      Artem Pelenitsyn authored
  2. 11 Jul, 2020 1 commit
    • Simon Peyton Jones's avatar
      Improve eta-expansion using ArityType · 2b7c71cb
      Simon Peyton Jones authored
      As #18355 shows, we were failing to preserve one-shot info when
      eta-expanding.  It's rather easy to fix, by using ArityType more,
      rather than just Arity.
      This patch is important to suport the one-shot monad trick;
      see #18202.  But the extra tracking of one-shot-ness requires
      the patch
         Define multiShotIO and use it in mkSplitUniqueSupply
      If that patch is missing, ths patch makes things worse in
      GHC.Types.Uniq.Supply.  With it, however, we see these improvements
          T3064     compiler bytes allocated -2.2%
          T3294     compiler bytes allocated -1.3%
          T12707    compiler bytes allocated -1.3%
          T13056    compiler bytes allocated -2.2%
      Metric Decrease:
  3. 10 Jul, 2020 2 commits
    • Simon Peyton Jones's avatar
      Make arityType deal with join points · bce695cc
      Simon Peyton Jones authored
      As Note [Eta-expansion and join points] describes,
      this patch makes arityType deal correctly with join points.
      What was there before was not wrong, but yielded lower
      arities than it could.
      Fixes #18328
      In base GHC this makes no difference to nofib.
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
               n-body          -0.1%     -0.1%     -1.2%     -1.1%      0.0%
                  Min          -0.1%     -0.1%    -55.0%    -56.5%      0.0%
                  Max          -0.0%      0.0%    +16.1%    +13.4%      0.0%
       Geometric Mean          -0.0%     -0.0%    -30.1%    -31.0%     -0.0%
      But it starts to make real difference when we land the change to the
      way mkDupableAlts handles StrictArg, in fixing #13253 and friends.
      I think this is because we then get more non-inlined join points.
    • Simon Peyton Jones's avatar
      Define multiShotIO and use it in mkSplitUniqueSupply · d9f09506
      Simon Peyton Jones authored
      This patch is part of the ongoing eta-expansion saga;
      see #18238.
      It implements a neat trick (suggested by Sebastian Graf)
      that allows the programmer to disable the default one-shot behaviour
      of IO (the "state hack").  The trick is to use a new multiShotIO
      function; see Note [multiShotIO].  For now, multiShotIO is defined
      here in Unique.Supply; but it should ultimately be moved to the IO
      The change is necessary to get good code for GHC's unique supply;
      see Note [Optimising the unique supply].
      However it makes no difference to GHC as-is.  Rather, it makes
      a difference when a subsequent commit
         Improve eta-expansion using ArityType
  4. 09 Jul, 2020 3 commits
    • Sylvain Henry's avatar
      LLVM: fix MO_S_Mul2 support (#18434) · 3656dff8
      Sylvain Henry authored
      The value indicating if the carry is useful wasn't taken into account.
    • Stefan Schulze Frielinghaus's avatar
      Fix GHCi :print on big-endian platforms · b7de4b96
      Stefan Schulze Frielinghaus authored
      On big-endian platforms executing
        import GHC.Exts
        data Foo = Foo Float# deriving Show
        foo = Foo 42.0#
        :print foo
      results in an arithmetic overflow exception which is caused by function
      index where moveBytes equals
        word_size - (r + item_size_b) * 8
      Here we have a mixture of units. Both, word_size and item_size_b have
      unit bytes whereas r has unit bits.  On 64-bit platforms moveBytes
      equals then
        8 - (0 + 4) * 8
      which results in a negative and therefore invalid second parameter for a
      shiftL operation.
      In order to make things more clear the expression
        (word .&. (mask `shiftL` moveBytes)) `shiftR` moveBytes
      is equivalent to
        (word `shiftR` moveBytes) .&. mask
      On big-endian platforms the shift must be a left shift instead of a
      right shift. For symmetry reasons not a mask is used but two shifts in
      order to zero out bits. Thus the fixed version equals
        case endian of
          BigEndian    -> (word `shiftL` moveBits) `shiftR` zeroOutBits `shiftL` zeroOutBits
          LittleEndian -> (word `shiftR` moveBits) `shiftL` zeroOutBits `shiftR` zeroOutBits
      Fixes #16548 and #14455
    • Adam Sandberg Eriksson's avatar
  5. 07 Jul, 2020 22 commits
  6. 03 Jul, 2020 9 commits
  7. 02 Jul, 2020 1 commit
    • Sylvain Henry's avatar
      NCG: correctly handle addresses with huge offsets (#15570) · 3cdd8d69
      Sylvain Henry authored
      Before this patch we could generate addresses of this form:
         movzbl cP0_str+-9223372036854775808,%eax
      The linker can't handle them because the offset is too large:
         ld.lld: error: Main.o:(.text+0xB3): relocation R_X86_64_32S out of range: -9223372036852653050 is not in [-2147483648, 2147483647]
      With this patch we detect those cases and generate:
         movq $-9223372036854775808,%rax
         addq $cP0_str,%rax
         movzbl (%rax),%eax
      I've also refactored `getAmode` a little bit to make it easier to
      understand and to trace.