clash-ghc 0.5.10 → 0.5.11

raw patch · 3 files changed

+34/−24 lines, 3 filesdep ~clash-libdep ~clash-preludedep ~unbound-generics

Dependency ranges changed: clash-lib, clash-prelude, unbound-generics

Files

• CHANGELOG.md +4/−0
• clash-ghc.cabal +5/−5
• src-ghc/CLaSH/GHC/LoadModules.hs +25/−19

@@ -1,5 +1,9 @@ # Changelog for the [`clash-ghc`](http://hackage.haskell.org/package/clash-ghc) package +## 0.5.11 *August 2nd 2015*+* New features:+  * Re-enable GHC's strictness analysis pass, which improves dead-code removal, which hopefully leads to smaller circuits.+ ## 0.5.10 *July 9th 2015* * New features:   * Use new VHDL backend which outputs VHDL-93 instead of VHDL-2002: generated VHDL is now accepted by a larger number of tools.

@@ -1,5 +1,5 @@ Name:                 clash-ghc-Version:              0.5.10+Version:              0.5.11 Synopsis:             CAES Language for Synchronous Hardware Description:   CλaSH (pronounced ‘clash’) is a functional hardware description language that@@ -59,7 +59,7 @@                       containers                >= 0.5.4.0,                       directory                 >= 1.2,                       filepath                  >= 1.3,-                      ghc                       >= 7.10.1,+                      ghc                       >= 7.10.1 && < 7.12,                       process                   >= 1.2,                       hashable                  >= 1.1.2.3,                       haskeline                 >= 0.7.0.3,@@ -67,14 +67,14 @@                       mtl                       >= 2.1.1,                       text                      >= 0.11.3.1,                       transformers              >= 0.4.2,-                      unbound-generics          >= 0.1,+                      unbound-generics          >= 0.1 && < 0.3,                       unordered-containers      >= 0.2.1.0, -                      clash-lib                 >= 0.5.9,+                      clash-lib                 >= 0.5.10 && < 0.6,                       clash-systemverilog       >= 0.5.7,                       clash-vhdl                >= 0.5.8,                       clash-verilog             >= 0.5.7,-                      clash-prelude             >= 0.9,+                      clash-prelude             >= 0.9.2,                       ghc-typelits-natnormalise >= 0.3    if os(windows)

@@ -194,6 +194,7 @@              , Opt_FloatIn -- Moves let-bindings inwards, although it defeats the normal-form with a single top-level let-binding, it helps with other transformations              , Opt_DictsStrict -- Hopefully helps remove class method selectors              , Opt_DmdTxDictSel -- I think demand and strictness are related, strictness helps with dead-code, enable+             , Opt_Strictness -- Strictness analysis helps with dead-code analysis. However, see [NOTE: CPR breaks CLaSH]              ]      unwanted = [ Opt_LiberateCase -- Perform unrolling of recursive RHS: avoid@@ -215,23 +216,28 @@                , Opt_OmitInterfacePragmas -- We need all the unfoldings we can get                , Opt_IrrefutableTuples -- Introduce irrefutPatError: avoid                , Opt_Loopification -- STG pass, don't care-               -- TODO: Enable this optimization again. At the moment we disable-               -- it because it causes GHC to do the so-called "Constructed-               -- Product Result" (CPR) analysis, which in turn creates an-               -- annoying worker/wrapper which does the following:-               ---               --   * Scrutinise a Signal, and pack the head and tail of the-               --     Signal in an unboxed tuple.-               --   * Scrutinise on the unboxed tuple, and recreate the Signal.-               ---               -- This is problematic because the 'Signal' type is essentially treated as a "transparent"-               -- type by the CLaSH compiler, so observing its constructor leads to all kinds-               -- of problems.-               ---               -- Ultimately we should stop treating Signal as a "transparent" type and deal-               -- handling of the Signal type, and the involved co-recursive functions,-               -- properly. At the moment, CLaSH cannot deal with this recursive type and the-               -- recursive functions involved, and hence we need to disable this useful transformation. After-               -- everything is done properly, we should enable it again.-               , Opt_Strictness -- Strictness analysis helps with dead-code analysis... but,see TODO above                ]++-- [NOTE: CPR breaks CLaSH]+-- We used to completely disable strictness analysis because it causes GHC to+-- do the so-called "Constructed Product Result" (CPR) analysis, which in turn+-- creates an annoying worker/wrapper which does the following:+--+--   * Scrutinise a Signal, and pack the head and tail of the+--     Signal in an unboxed tuple.+--   * Scrutinise on the unboxed tuple, and recreate the Signal.+--+-- This is problematic because the 'Signal' type is essentially treated as a "transparent"+-- type by the CLaSH compiler, so observing its constructor leads to all kinds+-- of problems.+--+-- The current solution is to disable strictness analysis in "CLaSH.Signal.Internal"+-- so that functions manipulating 'Signal' constructor do not get a strictness/+-- demand/CPR annotation, which in turn ensures GHC doesn't create worker/wrappers+-- for when these functions are called in user code.+--+-- Ultimately we should stop treating Signal as a "transparent" type and deal+-- handling of the Signal type, and the involved co-recursive functions,+-- properly. At the moment, CLaSH cannot deal with this recursive type and the+-- recursive functions involved, and hence we need to disable this useful transformation. After+-- everything is done properly, we should enable it again.