This is an archive of the discontinued LLVM Phabricator instance.

[compiler-rt] Move crt into builtins
ClosedPublic

Authored by phosek on Jun 28 2023, 9:57 AM.

Details

Summary

On Linux crt is typically use in combination with builtins. In the Clang
driver the use of builtins and crt is controlled by the --rtlib option.
Both builtins and crt also have similar build requirements where they
need to be built before any other runtimes and must avoid dependencies.
We also want builtins and crt these to be buildable separately from the
rest of compiler-rt for bootstrapping purposes. Given how simple crt is,
rather than maintaining a separate directory with its own separate build
setup, it's more efficient to just move crt into builtins. We still use
separate CMake option to control whether to built crt same as before.

This is an alternative to D89492 and D136664.

Diff Detail

Event Timeline

phosek created this revision.Jun 28 2023, 9:57 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 28 2023, 9:57 AM
phosek requested review of this revision.Jun 28 2023, 9:57 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptJun 28 2023, 9:57 AM
Herald added subscribers: Restricted Project, cfe-commits. · View Herald Transcript
phosek updated this revision to Diff 535452.Jun 28 2023, 9:58 AM
phosek edited the summary of this revision. (Show Details)Jun 28 2023, 1:45 PM
phosek added a comment.EditedJun 30 2023, 3:34 PM

@smeenai I'd appreciate your thoughts on this change. I'd like to move forward with one of the solutions for buildining crt with builtins and so far this seems like the most efficient one, but I'm open to other ideas.

smeenai accepted this revision.Jun 30 2023, 3:46 PM

Sorry, it's been a week :D I assume that crt doesn't need the builtins to be available for its configure (the way the rest of compiler-rt does)? If so, this LGTM.

compiler-rt/lib/builtins/CMakeLists.txt
56–57

While you're changing all these (is that important here or just a drive-by fix, btw?), could you either quote them or drop the ${} to prevent weird things from happening if we have have e.g. an AIX variable defined? (https://cmake.org/cmake/help/latest/command/if.html#variable-expansion for context for anyone not familiar with the issue here.)

This revision is now accepted and ready to land.Jun 30 2023, 3:46 PM

Sorry, it's been a week :D I assume that crt doesn't need the builtins to be available for its configure (the way the rest of compiler-rt does)? If so, this LGTM.

Great question, I checked and crt doesn't need builtins, just Clang headers, same as builtins.

Sorry, it's been a week :D I assume that crt doesn't need the builtins to be available for its configure (the way the rest of compiler-rt does)? If so, this LGTM.

Great question, I checked and crt doesn't need builtins, just Clang headers, same as builtins.

Cool, this does seem like the simplest and best way to go then.

This revision was landed with ongoing or failed builds.Jul 11 2023, 12:41 AM
This revision was automatically updated to reflect the committed changes.
phosek marked an inline comment as done.

I think reduplication of build logic makes sense but these are conceptually separate things. The compiler rt builtins are needed in many cases where the C start-up code isn't (e.g. baremetal OS code). Would moving it to a subdirectory of builtins/ work too? That way it's clearer which source files and tests are part of each component?

I think reduplication of build logic makes sense but these are conceptually separate things. The compiler rt builtins are needed in many cases where the C start-up code isn't (e.g. baremetal OS code). Would moving it to a subdirectory of builtins/ work too? That way it's clearer which source files and tests are part of each component?

That's certainly possible, although I'd also argue that crtbegin.c and crtend.c isn't the only code in builtins directory that fits into this category (that is not needed in environments like baremetal, requiring C library): for example atomic*.c, os_version_check.c, emutls.c, enable_execute_stack.c, eprintf.c, gcc_personality_v0.c, clear_cache.c and probably some more that I missed. If we're going to reorganize things, we should probably do it more holistically.

This change appears to break -DCOMPILER_RT_BUILD_CRT=OFF:

$ cmake -B build -S llvm -DCMAKE_BUILD_TYPE=Release -DCOMPILER_RT_BUILD_CRT=OFF -DLLVM_ENABLE_PROJECTS='clang;compiler-rt;lld'
...
CMake Error at cmake/modules/AddLLVM.cmake:1935 (add_dependencies):
  The dependency target "crt" of target "check-all" does not exist.
Call Stack (most recent call first):
  cmake/modules/AddLLVM.cmake:1975 (add_lit_target)
  CMakeLists.txt:1211 (umbrella_lit_testsuite_end)


CMake Error at cmake/modules/AddLLVM.cmake:1935 (add_dependencies):
  The dependency target "crt" of target "check-compiler-rt" does not exist.
Call Stack (most recent call first):
  cmake/modules/AddLLVM.cmake:1975 (add_lit_target)
  /home/nathan/cbl/src/llvm-project/compiler-rt/test/CMakeLists.txt:114 (umbrella_lit_testsuite_end)


CMake Error at cmake/modules/AddLLVM.cmake:1935 (add_dependencies):
  The dependency target "crt" of target "check-builtins" does not exist.
Call Stack (most recent call first):
  cmake/modules/AddLLVM.cmake:2001 (add_lit_target)
  /home/nathan/cbl/src/llvm-project/compiler-rt/test/builtins/CMakeLists.txt:112 (add_lit_testsuite)
...

This change appears to break -DCOMPILER_RT_BUILD_CRT=OFF:

$ cmake -B build -S llvm -DCMAKE_BUILD_TYPE=Release -DCOMPILER_RT_BUILD_CRT=OFF -DLLVM_ENABLE_PROJECTS='clang;compiler-rt;lld'
...
CMake Error at cmake/modules/AddLLVM.cmake:1935 (add_dependencies):
  The dependency target "crt" of target "check-all" does not exist.
Call Stack (most recent call first):
  cmake/modules/AddLLVM.cmake:1975 (add_lit_target)
  CMakeLists.txt:1211 (umbrella_lit_testsuite_end)


CMake Error at cmake/modules/AddLLVM.cmake:1935 (add_dependencies):
  The dependency target "crt" of target "check-compiler-rt" does not exist.
Call Stack (most recent call first):
  cmake/modules/AddLLVM.cmake:1975 (add_lit_target)
  /home/nathan/cbl/src/llvm-project/compiler-rt/test/CMakeLists.txt:114 (umbrella_lit_testsuite_end)


CMake Error at cmake/modules/AddLLVM.cmake:1935 (add_dependencies):
  The dependency target "crt" of target "check-builtins" does not exist.
Call Stack (most recent call first):
  cmake/modules/AddLLVM.cmake:2001 (add_lit_target)
  /home/nathan/cbl/src/llvm-project/compiler-rt/test/builtins/CMakeLists.txt:112 (add_lit_testsuite)
...

Thanks for this heads up, this should be addressed in rG926f3759ec62a8f170e76a60316cc0bdd9dd2ec9.

Thanks for this heads up, this should be addressed in rG926f3759ec62a8f170e76a60316cc0bdd9dd2ec9.

That didn't work, the actual fix turned out to be slightly more complex: D155126.

I think reduplication of build logic makes sense but these are conceptually separate things. The compiler rt builtins are needed in many cases where the C start-up code isn't (e.g. baremetal OS code). Would moving it to a subdirectory of builtins/ work too? That way it's clearer which source files and tests are part of each component?

That's certainly possible, although I'd also argue that crtbegin.c and crtend.c isn't the only code in builtins directory that fits into this category (that is not needed in environments like baremetal, requiring C library): for example atomic*.c, os_version_check.c, emutls.c, enable_execute_stack.c, eprintf.c, gcc_personality_v0.c, clear_cache.c and probably some more that I missed. If we're going to reorganize things, we should probably do it more holistically.

That is a good point and it would be nice to have more subdirectories (e.g. atomic should end up in libatomic.a). I was just suggesting subdirectories for this change since we already have an existing hierarchy that could be retained. Splitting things out later is slightly more involved.

compiler-rt/test/crt/CMakeLists.txt