Skip to content
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

TypeInterface and related refactoring #66

Open
ahueck opened this issue Apr 7, 2021 · 0 comments
Open

TypeInterface and related refactoring #66

ahueck opened this issue Apr 7, 2021 · 0 comments
Labels
enhancement New feature or request

Comments

@ahueck
Copy link
Contributor

ahueck commented Apr 7, 2021

This is likely backward compatibiliy breaking change.

TypeInterface

The type id numbering should be reworked (enum typeart_builtin_type_t ) to handle new types (see also #62) and be robust w.r.t. code changes.

Where to put a new type?

Currently: TA_PTR is 10 and TA_NUM_VALID_IDS is 11.
Potentially:

  • TA_PTR is 254, TA_UNKNOWN_TYPE is 255 and User-def. types start at 256 (as before).
  • TA_NUM_VALID could be "concrete LLVM type" + 1 (e.g., TA_PPC_FP128 + 1 or TA_NEW_TYPE + 1)

Needs (some) backward compat. in case a new type is added.

TypeDB & TypeManager

Both dependent on TypeInterface refactoring.

TypeDB

  • BuiltinNames/Sizes should be generated (or checked) dependent on TypeInterface.
  • Query functions should be checked after refactoring.
  • What about isUserDefinedType w.r.t. TA_USER_DEF flag etc.?

TypeManager

  • Adapt getOrRegisterType, see also reserveNextId
@ahueck ahueck added the enhancement New feature or request label Apr 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant