Add support for more Int types & Refactor files #27
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.
Simplifies the logic for creating Integer types for call LLVM instructions and LLVM Arithmetic intrinsic functions. Any signed integer type that is 64 bits and below is currently supported (
i8
,i16
,i32
,i64
andisize
).TODO: add support for unsigned type. In theory, this should be very similar to signed integers (requires modification of constraints and z3 variables).Update: support for unsigned types are trickier than expected. LLVM does not preserve the type and lifts all unsigned to be signed values. Intrinsic functions still use the unsigned counterparts, but use signed arguments (and handles the operations correctly). There still seems to be a notion of unsigned type when running the program, but unclear where this is from. (Look at README for a stack overflow article)
Testing framework also updated to create the temp test directory if it does not already exist (otherwise there will be a panic).
TODO: update the temp test dir logic to be deleted afterwards (possibly).Update: Added new tests for each signed type that is currently supported (i8, i16, i32 & i64). i128 is not currently implemented due to the Z3 binding working with values up to i64 easily (whereas, a different conversion to a Z3
Int
would be needed for larger int types).Lastly, files and modules refactored into a nested structure. Lib and imports have been rearranged.