-
Notifications
You must be signed in to change notification settings - Fork 159
Improved -fclash-debug-*
flags
#1847
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
Conversation
clash-lib/src/Clash/Driver/Types.hs
Outdated
instance Hashable DebugOpts where | ||
hashWithSalt s DebugOpts{..} = | ||
s `hashWithSalt` | ||
opt_invariants `hashWithSalt` | ||
opt_transformationInfo `hashSet` | ||
opt_transformations `hashWithSalt` | ||
opt_countTransformations `hashWithSalt` | ||
opt_transformationsFrom `hashWithSalt` | ||
opt_transformationsLimit `hashWithSalt` | ||
opt_historyFile | ||
where | ||
hashSet = Set.foldl' hashWithSalt | ||
infixl 0 `hashSet` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason to not just derive Hashable
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did wonder about that. Hashable
isn't derived for ClashOpts
, so when I defined this one I just moved the relevant lines from that instance + added the ones for the new fields to be safe
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm, my guess is that that's a leftover from a feature/hack we've since moved to the right place?:
clash-compiler/clash-lib/src/Clash/Driver/Manifest.hs
Lines 370 to 408 in aaf1559
optsHash = hash opts { | |
-- Ignore the following settings, they don't affect the generated HDL: | |
-- 1. Debug | |
opt_dbgLevel = DebugNone | |
, opt_dbgTransformations = Set.empty | |
, opt_dbgRewriteHistoryFile = Nothing | |
-- 2. Caching | |
, opt_cachehdl = True | |
-- 3. Warnings | |
, opt_primWarn = True | |
, opt_color = Auto | |
, opt_errorExtra = False | |
, opt_checkIDir = True | |
-- 4. Optional output | |
, opt_edalize = False | |
-- Ignore the following settings, they don't affect the generated HDL. However, | |
-- they do influence whether HDL can be generated at all. | |
-- | |
-- We therefore check whether the new flags changed in such a way that | |
-- they could affect successful compilation, and use that information | |
-- to decide whether to use caching or not (see: XXXX). | |
-- | |
-- 1. termination measures | |
, opt_inlineLimit = 20 | |
, opt_specLimit = 20 | |
-- 2. Float support | |
, opt_floatSupport = False | |
-- Finally, also ignore the HDL dir setting, because when a user moves the | |
-- entire dir with generated HDL, they probably still want to use that as | |
-- a cache | |
, opt_hdlDir = Nothing | |
} |
I think we can just remove it and derive Hashable
- in a separate commit of course so we can rollback if necessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, Set String
has no Hashable
instance, so deriving would fail
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And same for OverridingBool
in ClashOpts
. So I guess without making any more *.Extra
modules we wouldn't be able to derive these instances
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah. Do we rely on the ordering? HashSet
is generally preferable anyway. Which would leave OverridingBool
- I guess an orphan instance wouldn't hurt.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we rely on the ordering?
No, it's just a set of transformations which are whitelisted for showing in the debug logs. I had thought that there should probably be a later commit to change it from String
to Text
, maybe that should be a commit to change it from Set String
to HashSet Text
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yesss :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think I'm going to save this kind of type shake-up for a future PR, there are a few places where the types in rewrite / normalize could be improved and fiddling with types seems a bit tangential to this PR
3e89582
to
1237446
Compare
2892b80
to
e4520b3
Compare
@leonschoorl I've changed |
Things like the count of transformations applied and the offset / limits for transformations when debugging cannot be negative, so it makes more sense to use Word instead of Int for these.
7240791
to
5a93512
Compare
Wow, the term in IntegralTB with 8.10 is so big is doesn't even get to print the actually error. |
That's how you know it's |
Don't change when type-change-errors are reported compared to how it is now on HEAD of |
Yeah, seems reasonable. It'll be a little non-obvious to read with the new check (what does the amount of info printed about transformed terms have to do with type errors?) but the behaviour will be identical. I'll leave a comment for archaeology / to reference to #1064 so it's clearer to anyone who happens across it in the future |
The debugging options for the compiler are often used together, yet are passed individually to the rewrite system. Keeping debugging options together helps expose less unnecessary detail.
-- not keep casts, so "illegally" changing between `Signal dom a` and `a` | ||
-- will trigger this error for many designs. | ||
-- | ||
-- This should be changed when #1064 (PR to keep casts in core) is merged. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apart from casts, wasn't this also triggered by separateArguments
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The implicit params thing? Yeah, I didn't include that because by the time the signal cast PR is in it might not be an issue / there might be other small issues so I didn't want to get too into detail past the most immediate obstacle
The old
DebugLevel
style debug options are replaced with a more granular style, where different options can be set independently. This allows things not previously possible, such as counting transformations without having to print any normalized core.The old
-fclash-debug
flag still works in the same way for backwards compatibility. Additional command line flags are now available to directly set options from the new type:-fclash-debug-invariants
checks for invariants and displays warnings / errors. Setting this alone is equivalent toDebugSilent
.-fclash-debug-info
sets the amount of information to display when applying transformations. This overlaps a lot with the oldDebugLevel
type, but is named more consistently.-fclash-debug-count-transformations
counts the number of transformations applied (without showing any normalized core likeDebugCount
did)Additionally, the debugging options are now in their own type (
DebugOpts
) which is accessed directly through theRewriteEnv
inapply
/applyDebug
instead of having the individual debugging options passed as inputs to the function. This simplifies the logic slightly in these functions and avoids needing to callapplyDebug
recursively with modified values.Fixes #1800
Still TODO: