-
Notifications
You must be signed in to change notification settings - Fork 23
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
Add term simplification to Python bindings #897
Conversation
e4c3531
to
9d93cb5
Compare
I have also tested the booster's integration tests with this change applied and there is no breakage to the C bindings. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good in terms of functionality.
Python tests: runtimeverification/pyk#736
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's very difficult to follow these changes because they are a mix of a refactoring that moves a lot of code around, and new features. I'm concerned that despite my best efforts, I still wasn't really able to determine what code was "new" and review it effectively.
I think you need to refactor the history of this PR to more obviously break it into two components: the moving around of existing code, and the addition of new code.
This commit sets up an empty library that will be used to extract features currently implemented in _either_ the Python or C bindings, such that the two bindings can share code.
This commit reorganises the existing C bindings for the LLVM backend by extracting some of their AST manipulation code to the newly-created core bindings library. It does not change the set of features offered by the bindings; the diff does not look quite like a straight reorganisation because the implementation changes from "pure C" style to direct usage of the underlying C++ data structures, but the intent of the code remains identical.
33b638e
to
d422878
Compare
Builds on the refactoring performed in the previous commits by adding a new binding to the Python module that exposes the core library's term simplifier. A small amount of build system code is required to do so as well.
This test mimics existing Python bindings tests; it performs a few small smoke tests of the exposed features from the previous commits in this PR but leaves the bulk of the testing responsibility to Pyk.
d422878
to
707de47
Compare
|
||
kore_symbol_free(inj_sym); | ||
auto inj = new kore_pattern; | ||
inj->ptr_ = kllvm::bindings::make_injection(term->ptr_, from->ptr_, to->ptr_); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dwightguth As an example of how to look at the changes in this diff, the kllvm::bindings::make_injection
function contains code that is equivalent to the C on the LHS here, but using the underlying C++ structures directly. All the changes in this commit are of that form.
auto inj_sym = KORESymbol::Create("inj"); | ||
|
||
inj_sym->addFormalArgument(from); | ||
inj_sym->addFormalArgument(to); | ||
|
||
auto inj = KORECompositePattern::Create(std::move(inj_sym)); | ||
inj->addArgument(term); | ||
|
||
return inj; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The restated C++ code from my other comment is here.
This function got missed out when I rebased some commit history in #897
~Blocked on runtimeverification/llvm-backend#897 ~Blocked on runtimeverification/llvm-backend#910 Adds runtime methods `simplify` and `simplify_bool`. --------- Co-authored-by: devops <devops@runtimeverification.com>
~Blocked on runtimeverification/llvm-backend#897 ~Blocked on runtimeverification/llvm-backend#910 Adds runtime methods `simplify` and `simplify_bool`. --------- Co-authored-by: devops <devops@runtimeverification.com>
…n/pyk#736) ~Blocked on runtimeverification/llvm-backend#897 ~Blocked on runtimeverification/llvm-backend#910 Adds runtime methods `simplify` and `simplify_bool`. --------- Co-authored-by: devops <devops@runtimeverification.com>
…n/pyk#736) ~Blocked on runtimeverification/llvm-backend#897 ~Blocked on runtimeverification/llvm-backend#910 Adds runtime methods `simplify` and `simplify_bool`. --------- Co-authored-by: devops <devops@runtimeverification.com>
…n/pyk#736) ~Blocked on runtimeverification/llvm-backend#897 ~Blocked on runtimeverification/llvm-backend#910 Adds runtime methods `simplify` and `simplify_bool`. --------- Co-authored-by: devops <devops@runtimeverification.com>
…n/pyk#736) ~Blocked on runtimeverification/llvm-backend#897 ~Blocked on runtimeverification/llvm-backend#910 Adds runtime methods `simplify` and `simplify_bool`. --------- Co-authored-by: devops <devops@runtimeverification.com>
This PR exposes the concrete term simplification routines already used by the booster to the Python bindings so that they can be called from Pyk. Specifically, it adds two free functions to the
runtime
module:These are exposed as free functions because they depend on the runtime library and so can't be automatically bound to the
Pattern
class as methods; I suggest Pyk probably wants to monkey-patch them into itsPattern
class along with some kind of dynamic check for whether theruntime
module has been loaded or not.Previously, the C and Python bindings didn't share a great deal of code; the simplification routine is the first bit of non-trivial behaviour that they need to share. I have therefore started a reorganisation of the bindings code to extract as much functionality to a common library, which has the additional benefit of reducing the amount of memory-leak prone handling of C wrapper structures. To keep the diff in this PR reasonable I have not completed this migration, but this is future work that I will complete in a future PR.
A summary of the changes in this PR is as follows:
Int
andBool
; these are really just smoke tests and Pyk should test the feature more thoroughly.