diff --git a/CHANGELOG.md b/CHANGELOG.md
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -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.
diff --git a/clash-ghc.cabal b/clash-ghc.cabal
--- a/clash-ghc.cabal
+++ b/clash-ghc.cabal
@@ -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)
diff --git a/src-ghc/CLaSH/GHC/LoadModules.hs b/src-ghc/CLaSH/GHC/LoadModules.hs
--- a/src-ghc/CLaSH/GHC/LoadModules.hs
+++ b/src-ghc/CLaSH/GHC/LoadModules.hs
@@ -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.