Conversation
| ifeq ($(EMBEDDED_CLANG),no) | ||
| ENZYME_LOAD_FLAGS += -fplugin=$(ENZYME_PATH) | ||
| REACTANT_PLUGIN_FLAGS += -fplugin-arg-enzyme-raising-plugin-path=$(LIB_RAISE_PATH) | ||
| REACTANT_PLUGIN_FLAGS += -fplugin-arg-enzyme-reactant-backend=cuda |
There was a problem hiding this comment.
the -mllvm -reactant-backend -mllvm cuda version works on the plugin too.
Separately can you make the backend another makefile option?
There was a problem hiding this comment.
Agreed, but for some reason, the bazel-built plugin processes -mllvm options before loading the plugin using -fplugin=/-load , which leads to a unknown option error.
I just switched to using frontend ParseArgs, and this works now.
For CMake built plugins, both ways(frontend parse args/ -mllvm works).
For bazel built plugins, only the frontend parse args work(but libraise is statically linked in)
reactant-clang obviously supports mllvm
|
|
||
| clean: | ||
| rm -rf $(program) *.o *.re_export | ||
| rm -f args.c.re_export lbm lbm.cu.re_export lbm_kernel.cu.re_export main.cc.re_export out.txt parboil_cuda.c.re_export |
There was a problem hiding this comment.
Ah I just pasted my untracked git files, will fix
There was a problem hiding this comment.
I think the existing clean should be correct
2 participants
Bazel plugin builds for reactant error out if we include lbm_kernel.cu during link, seems like a duplicate symbol bug in the code itself.