This patch unifies the handling of generating the GPU build targets
between the add_entrypoint_library and the add_object_library
functions. The _build_gpu_objects function will create two targets.
One contains a single object file with several GPU binaries embedded in
it, a so-called fatbinary. The other is a direct compile of the
supported target to be used internally only. This patch pulls out some
of the properties logic so that we can handle both more easily. This
patch also required adding an ovverride NO_GPU_BUILD for cases when
we only want to build the source file as normal.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
libc/cmake/modules/LLVMLibCObjectRules.cmake | ||
---|---|---|
199 | Look like NO_GPU_BUILD belongs to optional arguments, i.e. the line above. |
Overall it looks good to me, but let's wait for @sivachandra to comment on the patch.
Also, I just noticed that build_gpu_objects is called after FLAGS expansion (via the chain add_entrypoint_object -> expand_flags_for_entrypoint_object -> create_entrypoint_object -> build_gpu_objects),
so for an entry point object with some FLAGS properties (that are currently used to create multiple targets for different CPU configurations, especially in math functions), redundant GPU targets will be generated.
This is probably not a problem with the current set of entry points enabled for GPU yet.
Anyway since we are going to push CMake version to 3.20 matching LLVM updated requirements, it's probably a good time for me to revise the FLAGS implementations make sure it works well with other use cases.
LGTM, but I have left a naming suggestion.
libc/startup/gpu/nvptx/CMakeLists.txt | ||
---|---|---|
13 | The name NO_GPU_BUILD seems odd when you do have LIBC_GPU_TARGET_ARCHITECTURE. May be name it NO_GPU_BUNDLE? |
Look like NO_GPU_BUILD belongs to optional arguments, i.e. the line above.