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

OpenMP in the support libraries #2705

Open
AlexandreEichenberger opened this issue Feb 6, 2024 · 1 comment
Open

OpenMP in the support libraries #2705

AlexandreEichenberger opened this issue Feb 6, 2024 · 1 comment
Assignees

Comments

@AlexandreEichenberger
Copy link
Collaborator

We are interested in generating multiple threading code in the extension library, which we compile when targeting the NNPA accelerator. This runtime is loaded into the .so model, and is compiled when we build onnx-mlir (like the cruntime, for example).

If we introduce parallelism while building onnx-mlir, it is key that we use the llvm compiler with an OpenMP enabled. There would be generally two options that I can think of (maybe there are others).

  1. Use the llvm-project we already build for the 'mlir' support, and add 'clang' and 'OpenMP' to it.
  2. Use a locally build llvm with OpenMP (maybe there is a way to download it easily in our docker,...

Parallel is not enabled by default yet, we would like to extend its usage from currently only in the generated model to also some of the underlying support libraries that are bundled with the .so model.

@gongsu832
Copy link
Collaborator

We already do #1 and build a libompruntime.a to be embedded into the model runtime. The command currently used to generate the model runtime is:

clang++-18 ./docs/doc_example/add.o -o ./docs/doc_example/add.so -shared -fPIC -L/opt/Downloads/temp/onnx-mlir/build-shared-openmp/Debug/lib -lcruntime -lompruntime -lRuntimeNNPA -lzdnn

As you can see, in order to allow the extensions such as RuntimeNNPA to use ompruntime, all it takes is to put the extension libraries in front of cruntime and ompruntime. This can be done easily with adding an optional parameter to addCompilerConfig so that extension libraries are added at the head of the vector as oppose to at the tail by default.

Note that it's always safe to put extension libraries in front of cruntime and ompruntime since they should never depend on the extension libraries which may not exist.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants