- 
          
- 
                Notifications
    You must be signed in to change notification settings 
- Fork 41
Feature/int widths #96
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
base: master
Are you sure you want to change the base?
Changes from all commits
3a775c5
              6f8dc25
              6fa37fb
              7031e6d
              1a6000e
              f65fb98
              15566d1
              0b36cf7
              49155b1
              0534d82
              9805dbc
              6e3ff13
              fe7ab7a
              a299077
              5ad9bde
              7bc134b
              ae5c55c
              0aa77a6
              File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | 
|---|---|---|
|  | @@ -24,8 +24,8 @@ import AbstractInterpretation.HeapPointsTo.CodeGenBase (HPTMapping) | |
| type Loc = Int | ||
|  | ||
| data SimpleType | ||
| = T_Int64 | ||
| | T_Word64 | ||
| = T_Int Word32 | ||
| | T_Word Word32 | ||
| There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would use Word32 as a parameter to define the concrete width of these types. Some ADT which is better aligned with the LLVM types would be better. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I originally used  There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ah got it, if LLVM-hs uses in the API than no objections from my side anymore :) | ||
| | T_Float | ||
| | T_Bool | ||
| | T_Unit | ||
|  | @@ -99,8 +99,8 @@ concat <$> mapM makeLenses [''NodeSet, ''TypeSet, ''HPTResult] | |
| toSimpleType :: IR.SimpleType -> SimpleType | ||
| toSimpleType = \case | ||
| -1 -> T_Unit | ||
| -2 -> T_Int64 | ||
| -3 -> T_Word64 | ||
| -- -2 -> T_Int w | ||
| -- -3 -> T_Word w | ||
| -4 -> T_Float | ||
| -5 -> T_Bool | ||
| -6 -> T_String | ||
|  | ||
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.
@csabahruska do you have an existing plan how to implement this in these abstract interpretations?
Uh oh!
There was an error while loading. Please reload this page.
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.
I was wondering a bit while I was writing this why a mapping from types to registers wasn't handled by
Data.Mapor something similar. Maybe assigning a unique type to the next available register would work?