Skip to content

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

Merged
merged 2 commits into from
Jun 18, 2021
Merged

Improved -fclash-debug-* flags #1847

merged 2 commits into from
Jun 18, 2021

Conversation

alex-mckenna
Copy link
Contributor

@alex-mckenna alex-mckenna commented Jun 8, 2021

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 to DebugSilent.
  • -fclash-debug-info sets the amount of information to display when applying transformations. This overlaps a lot with the old DebugLevel type, but is named more consistently.
  • -fclash-debug-count-transformations counts the number of transformations applied (without showing any normalized core like DebugCount did)

Additionally, the debugging options are now in their own type (DebugOpts) which is accessed directly through the RewriteEnv in apply / 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 call applyDebug recursively with modified values.

Fixes #1800

Still TODO:

  • Write a changelog entry (see changelog/README.md)
  • Check copyright notices are up to date in edited files

@alex-mckenna alex-mckenna requested a review from leonschoorl June 8, 2021 14:26
Comment on lines 144 to 156
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`
Copy link
Member

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?

Copy link
Contributor Author

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

Copy link
Member

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?:

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.

Copy link
Contributor Author

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

Copy link
Contributor Author

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

Copy link
Member

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.

Copy link
Contributor Author

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?

Copy link
Member

Choose a reason for hiding this comment

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

Yesss :)

Copy link
Contributor Author

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

@alex-mckenna alex-mckenna force-pushed the issue-1800 branch 2 times, most recently from 3e89582 to 1237446 Compare June 8, 2021 15:20
@alex-mckenna alex-mckenna force-pushed the issue-1800 branch 2 times, most recently from 2892b80 to e4520b3 Compare June 11, 2021 12:06
@alex-mckenna
Copy link
Contributor Author

@leonschoorl I've changed applyDebug so it reports unexpected changes when dbg_invariants is on, as opposed to when the new analogue of DebugApplied is on. So if something like #1848 happens again the testsuite will pick it up

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.
@alex-mckenna alex-mckenna force-pushed the issue-1800 branch 2 times, most recently from 7240791 to 5a93512 Compare June 15, 2021 12:42
@leonschoorl
Copy link
Member

Wow, the term in IntegralTB with 8.10 is so big is doesn't even get to print the actually error.

@alex-mckenna
Copy link
Contributor Author

That's how you know it's working doing something. I guess I need to actually deal with the type change error instead of just downgrading it to a trace, it feels wrong to not include it in opt_invariants, or make it depend on an unrelated debugging option

@christiaanb
Copy link
Member

Don't change when type-change-errors are reported compared to how it is now on HEAD of master. The reporting is very fragile (asserts often) because we throw away all the casts. Until we properly support casts I wouldn't worry too much about these type-change-errors.

@alex-mckenna
Copy link
Contributor Author

Don't change when type-change-errors are reported compared to how it is now on HEAD of master.

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.
Copy link
Member

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?

Copy link
Contributor Author

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

@alex-mckenna alex-mckenna merged commit ad51aea into master Jun 18, 2021
@alex-mckenna alex-mckenna deleted the issue-1800 branch June 18, 2021 09:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Refactor DebugLevel logic to not use Ord
4 participants