[llvm-dev] What's the principle to add builtins in clang?

[chuanqi.xcq via llvm-dev]

Hi all,

Background: 
    Recently I am trying to enable the Coroutine Heap Elision in some code bases. Here is the introduction for Coroutine Heap Elision: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0981r0.html.
    Then in LLVM, we decide to elide one coroutine if we can prove coro.id, which marks a coroutine, passes coro.destroy for every path to exit entry of the current function.
    For example (uses if-else for simplicity):
```
coro foo() {
    %handle = call i8* @llvm.coro.id(...) 
    ; some works
    if (...)
        call void @llvm.coro.destroy(%handle)
    else {
       other works
call void @llvm.coro.destroy(%handle)
    }
}
```
    And it would be elided.
    And if:
```
coro foo() {
    %handle = call i8* @llvm.coro.id(...) 
    ; some works
    if (%handle)
        call void @llvm.coro.destroy(%handle)
}
```
   It wouldn't be elided. And I want to add a builtin to makr the corresponding coroutine is already dead. Let me call it `__builtin_coro_dead`. Then we can write:
```
coro foo() {
    %handle = call i8* @llvm.coro.id(...) 
    ; some works
    if (%handle)
        call void @llvm.coro.destroy(%handle)
    call void @__builtin_coro_dead(%handle)
}
```
    And it would be elided now.

Question:
    The described above is just a background. This thread doesn't aim to ask for whether it is good to use `__builtin_coro_dead` to solve the problems.
We could discuss it in another thread. Here my question is what's the principle to judge whether should we to add new builtins. Since the end users could
touch builtins while I can't search builtin in the Standard of C++ (N4878). So if we could add new builtins arbitrarily, it means the compiler writers could
change the language without changing the standard document, which is very very odd for me. I can't find related rules. So here to ask for your suggestion.

Thanks,
Chuanqi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210423/9c882eb4/attachment-0001.html>