Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make applyDebug's free variable check take the context into account #2624

Merged
merged 1 commit into from
Feb 27, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 23 additions & 6 deletions clash-lib/src/Clash/Rewrite/Util.hs
Original file line number Diff line number Diff line change
Expand Up @@ -2,7 +2,7 @@
Copyright : (C) 2012-2016, University of Twente,
2016 , Myrtle Software Ltd,
2017 , Google Inc.,
2021-2022, QBayLogic B.V.
2021-2023, QBayLogic B.V.
License : BSD2 (see the file LICENSE)
Maintainer : QBayLogic B.V. <[email protected]>

Expand Down Expand Up @@ -77,7 +77,7 @@ import Clash.Core.Type (Type (..), normalizeType)
import Clash.Core.Var
(Id, IdScope (..), TyVar, Var (..), mkGlobalId, mkLocalId, mkTyVar)
import Clash.Core.VarEnv
(InScopeSet, extendInScopeSet, extendInScopeSetList, mkInScopeSet,
(InScopeSet, extendInScopeSet, extendInScopeSetList, mkInScopeSet, notElemInScopeSet,
uniqAway, uniqAway', mapVarEnv, eltsVarEnv, unitVarSet, emptyVarEnv,
mkVarEnv, eltsVarSet, elemVarEnv, lookupVarEnv, extendVarEnv, elemVarSet,
differenceVarEnv)
Expand Down Expand Up @@ -173,12 +173,13 @@ apply = \s rewrite ctx expr0 -> do
return ()

if isDebugging opts
then applyDebug s expr0 hasChanged expr1
then applyDebug ctx s expr0 hasChanged expr1
else return expr1
{-# INLINE apply #-}

applyDebug
:: String
:: TransformContext
-> String
-- ^ Name of the transformation
-> Term
-- ^ Original expression
Expand All @@ -187,7 +188,7 @@ applyDebug
-> Term
-- ^ New expression
-> RewriteMonad extra Term
applyDebug name exprOld hasChanged exprNew = do
applyDebug ctx name exprOld hasChanged exprNew = do
nTrans <- Lens.use transformCounter
opts <- Lens.view debugOpts

Expand All @@ -212,9 +213,14 @@ applyDebug name exprOld hasChanged exprNew = do
let beforeTy = inferCoreTypeOf tcm exprOld
beforeFV = Lens.setOf freeLocalVars exprOld
afterTy = inferCoreTypeOf tcm exprNew
afterFV = Lens.setOf freeLocalVars exprNew
afterFV = filterFVs (Lens.setOf freeLocalVars exprNew)
newFV = not (afterFV `Set.isSubsetOf` beforeFV)
accidentalShadows = findAccidentialShadows exprNew
-- see NOTE [Filter free variables]
allowNewFVsFromCtx = name == "caseCon"
filterFVs | allowNewFVsFromCtx = Set.filter notInCtx
| otherwise = id
notInCtx v = notElemInScopeSet v (tfInScope ctx)

Monad.when newFV $
error ( concat [ $(curLoc)
Expand Down Expand Up @@ -266,6 +272,17 @@ applyDebug name exprOld hasChanged exprNew = do
before = showPpr exprOld
after = showPpr exprNew

-- NOTE [Filter free variables]
-- Since [Give evaluator acces to inscope let-bindings #2571](https://github.com/clash-lang/clash-compiler/pull/2571)
-- the evaluator can rewrite expressions using let bindings from the 'TransformContext',
-- these bindings may reference other things bound in the context which weren't
-- in the expression before, and in doing so introduces new free variables and
-- fails this check for new free variables.
-- To prevent this we filter out all variables from bound in the context.
-- But only during a caseCon transformation, to not weaken this check unnecessarily.
Comment on lines +276 to +282
Copy link
Member

@martijnbastiaan martijnbastiaan Jan 2, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
-- Since [Give evaluator acces to inscope let-bindings #2571](https://github.com/clash-lang/clash-compiler/pull/2571)
-- the evaluator can rewrite expressions using let bindings from the 'TransformContext',
-- these bindings may reference other things bound in the context which weren't
-- in the expression before, and in doing so introduces new free variables and
-- fails this check for new free variables.
-- To prevent this we filter out all variables from bound in the context.
-- But only during a caseCon transformation, to not weaken this check unnecessarily.
-- Since [Give evaluator acces to inscope let-bindings #2571](https://github.com/clash-lang/clash-compiler/pull/2571)
-- the evaluator can rewrite expressions using let bindings from the 'TransformContext'.
-- These bindings may reference other things bound in the context which weren't
-- in the expression before, and in doing so introduces new free variables. Consequently,
-- this fails a check that prevents new free variables from being introduced -
-- as this is a bug in all other cases. To prevent this we filter out all
-- variables from bound in the context. We only do this during a 'caseCon' transformation,
-- to not weaken this check unnecessarily.

I've reformatted / broke up sentences to make it easier to read.

I'm not sure about this though:

We only do this during a 'caseCon' transformation,
to not weaken this check unnecessarily.

Is this because the evaluator is only called in caseCon? In any case, I think we should defend why we think we only need to do it for caseCon in the note.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@christiaanb maybe you could comment on this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The evaluator is called in multiple places, including caseCon. But as @leonschoorl points out, the "introduce free variables" check is quite useful to catch bugs in the Clash compiler, so we want to leave it enabled in as many places as possible. So it's only disabled in caseCon as we have a confirmed "false positive" for that transformation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, this sounds like: we're aware this is an issue, and we're going to wait until another transformation calling the evaluator is going to blow up..

What we should do is check the other transformations calling the evaluator, check whether they suffer from the same issue, and add a comment explaining why we do (not) need a similar approach as introduced in this PR.




-- | Perform a transformation on a Term
runRewrite
:: String
Expand Down
1 change: 1 addition & 0 deletions tests/Main.hs
Original file line number Diff line number Diff line change
Expand Up @@ -801,6 +801,7 @@ runClashTest = defaultMain $ clashTestRoot
#endif
, outputTest "T2542" def{hdlTargets=[VHDL]}
, runTest "T2593" def{hdlSim=[]}
, runTest "T2623CaseConFVs" def{hdlLoad=[],hdlSim=[],hdlTargets=[VHDL]}
] <>
if compiledWith == Cabal then
-- This tests fails without environment files present, which are only
Expand Down
19 changes: 19 additions & 0 deletions tests/shouldwork/Issues/T2623CaseConFVs.hs
Original file line number Diff line number Diff line change
@@ -0,0 +1,19 @@
module T2623CaseConFVs where
import Clash.Prelude

topEntity = foo @System

foo :: forall dom. Signal dom (Vec 1 (Signed 2)) -> Signal dom Bool
foo = \input ->
let
scs :: Signal dom (Vec 1 Bool)
scs = bundle $ map f $ unbundle input
in
fmap bar scs


bar :: (KnownNat n) => Vec (n+1) Bool -> Bool
bar = fold (&&) . map (id)

f :: Signal dom a -> Signal dom Bool
f = const $ pure $ True
Loading