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

WIP/RFC: Add intrinsics for querying the debug level #45948

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

maleadt
Copy link
Member

@maleadt maleadt commented Jul 6, 2022

To enable a cheaper version of #37874, we want compiler support for querying the debug level. This PR prototypes such a feature in two different ways:

  • a Julia intrinsic function lowered by codegen;
  • an LLVM intrinsic that's lowered by the (to-be generalized) CPU features pas.

The former is the simplest, but ideally we also want this functionality for the system image. That normally done with the multiversioning pass, which would require the intrinsic to be an LLVM intrinsic, hence the second form. I'm however not sure how to best adapt the multiversioning pass, if it even is suitable for this, so @yuyichao I'd appreciate some thoughts here.

Alternatively we could only have this supported for JITted code and basically require users to make debug in order to get a debug sysimg, but that would be much less user friendly.

cc @KristofferC

@maleadt maleadt added the codegen Generation of LLVM IR and native code label Jul 6, 2022
@vchuravy
Copy link
Sponsor Member

vchuravy commented Jul 6, 2022

Hm I am a bit worried about codesize if we make it a multi-versioning property every @assert could lead to a duplication of the method.

@maleadt
Copy link
Member Author

maleadt commented Jul 6, 2022

Multiversioning could also support dispatching to the JIT at run time instead of cloning eagerly (although again I'm currently not familiar enough with the pass to implement such a feature).

@vchuravy
Copy link
Sponsor Member

vchuravy commented Jul 6, 2022

I think making it a Julia intrinsics and then marking branches that depend on it as cold would be a good first start and then we can later look at making it stronger.

That would also prevent it from giving different optimization results depending on if the flag is on and off (which would be a boon on my side). I recently got burned by allocation tracking changing optimization results and yielding false positives.

@maleadt
Copy link
Member Author

maleadt commented Jul 7, 2022

I recently got burned by allocation tracking changing optimization results and yielding false positives.

I don't think that matters here though. If you're running with -g2 (or however we want to activate this), it's expected that there may be additional allocations. But without it, we'd want to avoid whatever cost comes with the non-active debugging code, so having the JIT optimize it away seems essential to actually being able to use @check (or, again, however we'll expose this) broadly enough.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
codegen Generation of LLVM IR and native code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants