Skip to content

Tidy MLIR code generation

Atoli Huppe requested to merge tidy-limpet-code-generation into master

What does this MR do?

Make compilation smoother (especially for MLIR enabled builds):

  • less clutter in the build output (#243 (closed))
  • do not rebuild models that are up to date (because of how the CMake configuration was specified, the build system was not able to see that some models did not need to be built again when they were already built)

There are now 4 general target macros:

  • CPU_GENERATED
  • MLIR_CPU_GENERATED
  • MLIR_ROCM_GENERATED
  • MLIR_CUDA_GENERATED

By default all targets for a given model are built. However it is possible to define model specific macros to only generate code for specific targets.

For example if the macro ALIEVPANFILOV_MLIR_CPU_GENERATED is defined then only the code for the MLIR_CPU target will be generated. If we want to also generate code for MLIR_CUDA or MLIR_ROCM we would need to define ALIEVPANFILOV_MLIR_CUDA_GENERATED OR ALIEVPANFILOV_MLIR_ROCM_GENERATED as well.

I also moved the generated files (.mlir, .cc, .h, ...) from physics/limpet/imps_src to the (out of source) build directory. I don't know if they were here for a particular reason but they were cluttering the git commit tree because they would be modified when compiling new versions of openCARP and do not really need to stay in VCS because they are 100% automatically generated.

Related issues

Closes #243 (closed)

Author's checklist

  • Follow the Contribution Guidelines. Sign the CLA and add yourself to the list of contribtutors for your first contribution.
  • Describe your change in the CHANGELOG.md file in the top-level folder of the openCARP repository.
  • Apply the appropriate labels.
  • Does this commit add new dependencies? If no, just tick the box. If yes, please evaluate carefully if the additional dependency is a more sustainable option than including the functionality in own code. If the former, describe the dependency clearly, add them to the Software Management Plan and the installation instructions (*.md files, CMake files, Docker files etc.).

Reviewer's checklist

All reviewers can help ensure accuracy, clarity, completeness, and adherence to the Contribution Guidelines.

Reviewer

  • Review by a code reviewer or other selected colleague to confirm accuracy, clarity, and completeness. This can be skipped for minor fixes without substantive content changes.

Maintainer

  • Review by assigned maintainer, who can always request/require the above reviews.
Edited by Axel Loewe

Merge request reports