One use case not covered by the current spec is the ability to match on a given basic block (or series of basic blocks). While current matching tools are meant to locate at the function level, there is an interesting series of problems one might be able to solve if given the ability to identify basic blocks, seperate from a function.
Some specific examples:
- Identification of inlined functions (see: 1)
- Matching constraints on a basic block level
- Function similarity (i.e. non-identical function can be compared)
For this to be possible there is two specific changes need to the spec:
- We must be able to store a list of ordered basic blocks on a function.
- We must be able to store a trie of basic blocks, then end node being a
ComputedBasicBlock (name is not final).
The ComputeBasicBlock is analogous to the Function table that already exists. It would represent a single analysis unit that stores all the information one would want to query when a series of basic blocks match.
What is some information we could store?
- Storing the function its attached to might be useful?
- Labels, comments, etc...
- Variable definitions (name and type)
- What else?
One use case not covered by the current spec is the ability to match on a given basic block (or series of basic blocks). While current matching tools are meant to locate at the function level, there is an interesting series of problems one might be able to solve if given the ability to identify basic blocks, seperate from a function.
Some specific examples:
For this to be possible there is two specific changes need to the spec:
ComputedBasicBlock(name is not final).The
ComputeBasicBlockis analogous to theFunctiontable that already exists. It would represent a single analysis unit that stores all the information one would want to query when a series of basic blocks match.What is some information we could store?