-
Notifications
You must be signed in to change notification settings - Fork 707
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
Rewrite various ad-hoc analyses to fix-point computations #536
Comments
For posterity, this is the |
Also, if we do this refactoring such that we calculate these things for all types in a single pass, we can avoid re-walking portions of the IR graph repeatedly, like we do now. |
@chmln, is this something you might be interested in hacking on? |
@fitzgen Yes 👍 |
@chmln awesome! It's not time critical. First things first: makes sure you can build As far as these analyses go, let's jsut start with one. However, we already have generic graph traversal infrastructure for our IR, see Additionally, we can do a single pass over the whole IR graph and build a Does that make sense? Don't hesitate to ask questions if anything is confusing, or you get stuck, or anything like that. |
As far as where to store the |
Perfect, thanks @fitzgen 👍 |
@chmln how are things going? Can I answer any questions for you? |
@fitzgen planning to complete it this weekend (slow progress due to busyness). |
@chmln how are things going? Still making some slow-but-steady progress? Anything I can do to help or questions I can answer? |
@fitzgen only question so far is about the location of the HashTable for vtables. Should it be in |
Yep! I'd probably put it near the |
ok @fitzgen I've gotten the traversal and everything working. The current |
@chmln great!
You can use matches something like this: match item.kind() {
&ItemKind::Type(ref ty) => {
// use ty.kind() here...
}
// other ItemKind cases ...
} Or use the if let Some(ty) = item.as_type() {
// use ty.kind() here...
} Does this clear up your question? |
@Tiwalun this meta issue has some stuff available that you might be able to help with :) @chmln is refactoring the |
@fitzgen Ok, I'll have a look at the |
@fitzgen nearly done with |
@Tiwalun still poking at |
Unassigned due to lack of activity. Also split out each bit of work into its own issue. |
#765 (comment) contains a skeleton for a new sample fixpoint analysis. It could be a good jumpoff point for any of sub-issues. |
This is a meta issue, see sub-issues for actual work items to help out.
I just spent an embarrassing amount of time debugging a stack overflow (like a dummy, I didn't hit
bt
immediately...) and it was becausehas_vtable
got caught in an infinite loop (with my local changes).All of
has_vtable
(Rewritehas_vtable
checks as either graph traversal or fix-point analysis #765)can_derive_copy[_in_array]
(Rewritecan_derive_copy[_in_array]
as either a graph traversal or fix-point analysis #766)can_derive_debug
(Rewritecan_derive_debug
as either a graph traversal or fix-point analysis #767)is_unsized
(Rewriteis_unsized
as a fix-point analysis #768)can_derive_default
(Rewritecan_derive_default
as a fix-point analysis #856)has_destructor
(Rewritehas_destructor
as a fixed point analysis #927)could be rewritten as graph traversals (or fix point computations). We just have to be careful to consider only the correct edges (eg ignore a class's class members, etc).
If they were re-written as graph traversals (or fix point computations), then they wouldn't be recursive and we wouldn't blow the stack. Additionally, some of these things add a
Cell<bool>
member that gets set during recursion, and we use this to detect cycles and avoid infinite recursion. These members would not be necessary with either a graph traversal or fix-point computation.Leaving this as a meta issue for rewriting each of these things.
The text was updated successfully, but these errors were encountered: