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

Documentation to Use SPARTA #3

Closed
ashispapu opened this issue Feb 28, 2019 · 1 comment
Closed

Documentation to Use SPARTA #3

ashispapu opened this issue Feb 28, 2019 · 1 comment

Comments

@ashispapu
Copy link

ashispapu commented Feb 28, 2019

Hi Team,

Thank you for releasing SPARTA. I am trying to explore different functionalities and APIs of SPARTA.However I am not able to find any document which explains the usage of SPARTA. Please let me know if there is any detailed document and examples to use SPARTA for different applications.
@int3 @facebook-github-bot , Any help is highly appreciated.
Thank you.
Ashis

@ashispapu ashispapu changed the title Documenattion o Use SPARTA Documentation to Use SPARTA Mar 1, 2019
@arnaudvenet
Copy link
Contributor

All header files contain documentation and code snippets that explain how to use the various data structures. The unit test MonotonicFixpointIteratorTest shows how to set up a complete analysis (live variables) for a toy language.

Since SPARTA is programming-language independent, the documentation doesn't go into all the details of analyzing a real programming language. The Android bytecode optimizer Redex makes extensive use of SPARTA for its optimization passes and I would recommend browsing the code base for more realistic use cases. The interprocedural constant propagation would be a great example: it uses nearly every single data structure in SPARTA and it's also very well documented.

facebook-github-bot pushed a commit that referenced this issue Aug 23, 2022
Summary:
This diff introduces two main changes:

### Update Graph interface
Currently, `predecessors` and `successors` in Graph trait returns `&[Self::EdgeId]`, this would be fairly efficient for Graph implementations that can return a slice. But I realized that in many cases, the Graph implementations may only be able to return an iterator (e.g., using petgraph). To make the interface more flexible, I decide to update it.

There are three options for the new return type:
```
// 1. A iterator trait object (lazily evaluated, dynamic dispatch).
fn predecessors(&self, n: Self::NodeId) -> Box<dyn Iterator<Item = Self::EdgeId> + '_>;

// 2. Vector (heap alloc).
fn predecessors(&self, n: Self::NodeId) -> Vec<Self::EdgeId>;

// 3. SmallVec is similar to LLVM SmallVector, which can hold data in stack if its size is smaller than S.
fn predecessors(&self, n: Self::NodeId) -> SmallVec<[Self::EdgeId; S]>;
```

With some benchmarking using different numbers of successors (etc.,1, 2, 4, 6, 8, 10),  it turns out that the option #1 and #2 has similar performance, while option #3 is always slightly better than the other two. So I decided to adopt it. This will introduce a new dependency to our library but it's small. (later I can put this kind of benchmarking code in a separate bench folder.)

### Add a new trait for getting successor nodes

In WPO, we need an interface to query the successor nodes of a given node. Previously I used a closure for it (while the C++ version uses std::function). After discussing with yuxuanchen1997, we think it's better to make this a separate trait to achieve this, so we add `SuccessorNodes` (The type that implements Graph trait can also implement Fn trait, but it's not recommended in Rust). In most cases, the same type can implement both. But they can also be separate types.

In addition, this diff adds a naive graph implementation for testing. In this diff we only use it to test the `get_succ_nodes` interface.

Reviewed By: yuxuanchen1997

Differential Revision: D38846203

fbshipit-source-id: 7951b83a7df6817b3796c1a4e40d85e08b4c2c12
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

No branches or pull requests

2 participants