5 ms·

I'm excited for the release of [[clang::musttail]], an attribute that I implemented to bring guaranteed tail calls to C, C++, and Objective-C: https://releases.

I'm excited for the release of [[clang::musttail]], an attribute that I implemented to bring guaranteed tail calls to C, C++, and Objective-C: https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNotes.html#major-new-features https://releases.llvm.org/13.0.0/tools/clang/docs/ReleaseNot... I talked more about some performance motivation for this feature here: https://blog.reverberate.org/2021/04/21/musttail-efficient-interpreters.html https://blog.reverberate.org/2021/04/21/musttail-efficient-i...

ndesaulniers 5y ago
I worry whether LLVM can actually provide such guarantees ATM. https://reviews.llvm.org/D107872 https://reviews.llvm.org/D107872 makes me doubt.
- haberman 5y ago
  Yes I think there are some bugs to be worked out still. I implemented Clang's [[clang::musttail]] attribute on top of the existing LLVM "musttail" attribute, but it does appear that there are some issues with the existing attribute at the LLVM level. In addition to the bug you mentioned, there are a few architectures where musttail is not supported supported. The POWER backend (big endian or pre-POWER10) and ARM backend (32-bit only) will throw errors for musttail in the backend. In the long-term though, I see this being a solid foundation on which to build. x86/x64/ARM64/POWER10 all support it. All the architectures seem to be going in a direction where this is possible to guarantee. Hopefully the bugs will get ironed out over time. Thanks for your bugfix on this!
  - google234123 5y ago
    Welcome to the future of C++ :) [[clang::musttail]] [[deprecated]] [[nodiscard]] static inline bool& func(...) noexcept {...}
    - Matheus28 5y ago
      You forgot constexpr
      - sitkack 5y ago
        CppCon 2017: Ben Deane & Jason Turner “constexpr ALL the Things!” https://www.youtube.com/watch?v=PJwd4JLYJJY https://www.youtube.com/watch?v=PJwd4JLYJJY
    - ndesaulniers 5y ago
      [[always_inline (for real though this time)]]
    - ufo 5y ago
      To be pedantic... the musttail attribute goes in the return statement with the function call, not on the function definition.
    - vlovich123 5y ago
      Attributes don't need to go in separate sections though: [[clang::musttail, deprecated, nodiscard]]. Also unfortunately the inline keyword doesn't really do much except make the author feel happy they thought the compiler they told it to inline that function.
    - wahern 5y ago
      I'm more of a C programmer, not C++, but several years ago I switched to BSD/KNF style for function definitions because it improved consistency and diff-friendliness when managing qualifiers and attributes. BSD/KNF style is, int foo(int a, int b) { ... } This lends itself to prepending and appending qualifiers as separate lines, like __attribute__((unused)) __attribute__((format (printf 1, 2))) static inline char * sformat(const char *fmt, ...) { ... } Often I'll split linkage qualifiers (static inline) from return type (char *), especially when linkage is controlled by a macro. K&R and Linux styles are similar: int foo(int a, int b) { ... } Function prototype styles are the same across BSD/KNF, K&R, and Linux, keeping the return type on the same line as the identifier, but I'll often put linkage qualifiers and sometimes even return types on their own line, especially if there are other attributes as well. Note: All these styles normally place braces on the same line as control flow statements. Function definitions are treated differently for what I understand in hindsight are good (if possibly serendipitous) reasons. C++ complicates things with methods, template, etc, so I'm not sure how well the above styles fit C++. In what little C++ I've written one of my first gripes was with difficulties controlling linkage, period.
  - ndesaulniers 5y ago
    > The POWER backend (big endian or pre-POWER10) and ARM backend (32-bit only) will throw errors for musttail in the backend. Hopefully it's just a bug in those backends, and not that the C++ standards committee ratified something that's impossible to support on certain architectures.
    - haberman 5y ago
      I don't believe musttail has been considered by the C++ standards committee, has it? Right now the Clang attribute is a Clang-only non-standard extension. I believe the backend issues mostly center around DSOs. I am hoping that the dso_local attribute can help out here: https://llvm.org/docs/LangRef.html#runtime-preemption-specifiers https://llvm.org/docs/LangRef.html#runtime-preemption-specif... If musttail only works for functions within the same DSO, that seems sufficient.
      - ndesaulniers 5y ago
        ah, sorry, I missed that it was a clang specific attribute.
sitkack 5y ago
Wow! This is amazing, you are amazing. Thank you!
- haberman 5y ago
  You are welcome, hope you find it useful!

ndesaulniers 5y ago

I worry whether LLVM can actually provide such guarantees ATM. https://reviews.llvm.org/D107872 https://reviews.llvm.org/D107872 makes me doubt.

haberman 5y ago
Yes I think there are some bugs to be worked out still. I implemented Clang's [[clang::musttail]] attribute on top of the existing LLVM "musttail" attribute, but it does appear that there are some issues with the existing attribute at the LLVM level. In addition to the bug you mentioned, there are a few architectures where musttail is not supported supported. The POWER backend (big endian or pre-POWER10) and ARM backend (32-bit only) will throw errors for musttail in the backend. In the long-term though, I see this being a solid foundation on which to build. x86/x64/ARM64/POWER10 all support it. All the architectures seem to be going in a direction where this is possible to guarantee. Hopefully the bugs will get ironed out over time. Thanks for your bugfix on this!
- google234123 5y ago
  Welcome to the future of C++ :) [[clang::musttail]] [[deprecated]] [[nodiscard]] static inline bool& func(...) noexcept {...}
  - Matheus28 5y ago
    You forgot constexpr
    - sitkack 5y ago
      CppCon 2017: Ben Deane & Jason Turner “constexpr ALL the Things!” https://www.youtube.com/watch?v=PJwd4JLYJJY https://www.youtube.com/watch?v=PJwd4JLYJJY
  - ndesaulniers 5y ago
    [[always_inline (for real though this time)]]
  - ufo 5y ago
    To be pedantic... the musttail attribute goes in the return statement with the function call, not on the function definition.
  - vlovich123 5y ago
    Attributes don't need to go in separate sections though: [[clang::musttail, deprecated, nodiscard]]. Also unfortunately the inline keyword doesn't really do much except make the author feel happy they thought the compiler they told it to inline that function.
  - wahern 5y ago
    I'm more of a C programmer, not C++, but several years ago I switched to BSD/KNF style for function definitions because it improved consistency and diff-friendliness when managing qualifiers and attributes. BSD/KNF style is, int foo(int a, int b) { ... } This lends itself to prepending and appending qualifiers as separate lines, like __attribute__((unused)) __attribute__((format (printf 1, 2))) static inline char * sformat(const char *fmt, ...) { ... } Often I'll split linkage qualifiers (static inline) from return type (char *), especially when linkage is controlled by a macro. K&R and Linux styles are similar: int foo(int a, int b) { ... } Function prototype styles are the same across BSD/KNF, K&R, and Linux, keeping the return type on the same line as the identifier, but I'll often put linkage qualifiers and sometimes even return types on their own line, especially if there are other attributes as well. Note: All these styles normally place braces on the same line as control flow statements. Function definitions are treated differently for what I understand in hindsight are good (if possibly serendipitous) reasons. C++ complicates things with methods, template, etc, so I'm not sure how well the above styles fit C++. In what little C++ I've written one of my first gripes was with difficulties controlling linkage, period.
- ndesaulniers 5y ago
  > The POWER backend (big endian or pre-POWER10) and ARM backend (32-bit only) will throw errors for musttail in the backend. Hopefully it's just a bug in those backends, and not that the C++ standards committee ratified something that's impossible to support on certain architectures.
  - haberman 5y ago
    I don't believe musttail has been considered by the C++ standards committee, has it? Right now the Clang attribute is a Clang-only non-standard extension. I believe the backend issues mostly center around DSOs. I am hoping that the dso_local attribute can help out here: https://llvm.org/docs/LangRef.html#runtime-preemption-specifiers https://llvm.org/docs/LangRef.html#runtime-preemption-specif... If musttail only works for functions within the same DSO, that seems sufficient.
    - ndesaulniers 5y ago
      ah, sorry, I missed that it was a clang specific attribute.

sitkack 5y ago

Wow! This is amazing, you are amazing. Thank you!

haberman 5y ago
You are welcome, hope you find it useful!