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

[chuanqi.xcq via llvm-dev]

Hi,

> I'm not really following this bit about changing the language without
> changing the standard document, or what builtins have to do with the
> C++ standard - could you explain this in more/different words,
> perhaps?

I mean the C++ users could use builtins in their source codes, Although this is not recommended.
In fact, in some projects which need to change the compiler move from GCC to Clang, I find some uses for some builtins.
My point is, although builtins are not part of the language standard, people could use the builtins in their code actually.
In other words, if the compiler adds new builtins, the actually semantic space would be larger than the design space.
That's what I said, we change the language in fact without changing the language standard documentation.

Thanks,
Chuanqi


------------------------------------------------------------------
From:David Blaikie <dblaikie at gmail.com>
Send Time:2021年4月24日(星期六) 02:51
To:chuanqi.xcq <yedeng.yd at linux.alibaba.com>
Cc:llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org>
Subject:Re: [llvm-dev] What's the principle to add builtins in clang?

On Fri, Apr 23, 2021 at 1:30 AM chuanqi.xcq via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> 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.

I'm not really following this bit about changing the language without
changing the standard document, or what builtins have to do with the
C++ standard - could you explain this in more/different words,
perhaps?

In general, builtins are a compiler implementation detail (nothing to
do with the C++ standard) and adding them is a tradeoff like adding
new instructions to LLVM IR (though builtins are lower cost than
instructions, generally - they're easier to add and remove/aren't such
a fundamental part of the IR): Does the new builtin or instruction
pull its weight: Adding new features to the IR in either case comes at
a cost of implementation complexity (now optimization passes need to
know about these new features) and if the semantics can be expressed
reasonably cleanly with existing IR features, that's preferable (or if
the IR feature can be generalized in some way to maximize the value
(make it more usable for a variety of problems people are having
trouble solving without it) while minimizing the cost (if it
generalizes well to something that is easy/reasonable for IR consumers
to handle/matches concepts they're already modeling/etc))

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210426/ae7a2c1f/attachment.html>