add ValueLattice abstraction and refactor TNum for known bits#553
Open
katrinafyi wants to merge 45 commits intomainfrom
Open
add ValueLattice abstraction and refactor TNum for known bits#553katrinafyi wants to merge 45 commits intomainfrom
katrinafyi wants to merge 45 commits intomainfrom
Conversation
this caused problems when bottom was undefined.
i want to be able to pass a value of ValueLattice which defines only a subset of the operations, to ensure that only width-independent functions are called on the provided `top` value. F-bound polymorphism makes it hideously hard to do this because any provided value must conform to `T <: ValueLattice[T]`, effectively forcing it to be a subtype of T (which is TNum here). if we were to make this restricted ValueLattice a subtype of TNum, we also have big problems. first, since TNum already defines all the methods, we would need to override them with implementations that throw. secondly, this overriding needs to happen in TNum and would need to be repeated if we wanted to do the same for other instances of ValueLattice in the future. this is deeply unsatisfying. honestly, idk what to do. i think that the "good" solution would be to make it all type-classes. then, we would be able to split up the "static" ops (width independent) with the non-static ops that need to be called on existing values. it would be very good to avoid the dual-purpose of ValueLattice as both a "dictionary of functions" and as a "lattice value". this is the root of problems here. when we pass around an abitrary (non-sound) value to access the directory of functions, we want to guarantee that the caller does not access the lattice value methods, because it would be unsound to do so.
This reverts commit aed3c9a.
also, seeing scalacheck failure which is concerning.
Member
Author
|
i've added a TypedLattice to abstract the bitwidth-dependence of the lattices BASIL/src/main/scala/analysis/ValueAnalysis.scala Lines 102 to 120 in 34bed33 however, there are still some problems:
|
Member
Author
|
re being able to define both width-deoendent and -independent methods and being able to choose which to use, ig the thing can be the thingy blah blah method parameter dictionary of functions guh |
Member
Author
|
related to #464 |
Contributor
0571287 to
f400e11
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
there is a big problem here with the Top value. the new ValueAnalysis infrastructure expects a unique value
top: Valuebut thetopin TNum requires a bit width parameter. i've arbitrarily set the bv1TNum.top(1)as "the" top value, and this causes the current test failures.(also, the TNum lattice is actually not really valid because values with differing widths are incompatible - meet/join will fail when given different widths.)
maybe we need an abstraction of bit-width which would allow the use of width-dependent lattices and coerce to Top when widths differ.