-
-
Notifications
You must be signed in to change notification settings - Fork 45
Centralise common backend routines and continue backend interface #808
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
Conversation
michalhabera
left a comment
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.
Moving the language backend independent code looks good, but I am not in favor of flattening the module structure to generator_form, etc. If this is the implementation detail, why not force user to prepare the module structure with classes then?
Co-authored-by: Michal Habera <[email protected]>
|
Reverted the flattening of the interface to free functions. Maintains the namespaced |
Centralises common backend logic for reusability in different backends.
template_keys: extracts template keys, used for checking all keys matched by input dataintegral_data: computes unrolled sorted integral data of aFormIRtensor_sizes: computes the sizes of the tensors associated with the kernel invocation of a form or an expressionConsistently names the implementation files in singular (
expressions.py->expression.py, etc.)All includes in code generation now pass though the module level, i.e.
__init__.pyofC/ornumba/- no longer enforcing a given file structure to be present in the backend (that's an implementation detail). This continues the work to define the language backend interface.The only thing that needs to be addressed/improved on after this for #805 is the handling of output files, the split into declaration and implementation (or header and source) should be generalised away from the backend.