<div class="__aliyun_email_body_block"><div  style="clear:both;"><span  style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;"><br ></span></div><div  style="clear:both;"><span  style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;">> <span  style="caret-color:#000000;color:#000000;font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;font-style:normal;font-variant-caps:normal;font-weight:normal;text-align:start;text-indent:.0px;text-transform:none;background-color:#ffffff;text-decoration:none;float:none;display:inline;">Ah, I think LLVM builtins aren't available to C++ source code by</span><br  style="caret-color:#000000;color:#000000;font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:.0px;text-transform:none;white-space:normal;widows:auto;word-spacing:.0px;"><span  style="caret-color:#000000;color:#000000;font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;font-style:normal;font-variant-caps:normal;font-weight:normal;text-align:start;text-indent:.0px;text-transform:none;background-color:#ffffff;text-decoration:none;float:none;display:inline;">> default - we wrap them in C intrinsics when that's desirable, for</span><br  style="caret-color:#000000;color:#000000;font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;orphans:auto;text-align:start;text-indent:.0px;text-transform:none;white-space:normal;widows:auto;word-spacing:.0px;"><span  style="caret-color:#000000;color:#000000;font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;font-style:normal;font-variant-caps:normal;font-weight:normal;text-align:start;text-indent:.0px;text-transform:none;background-color:#ffffff;text-decoration:none;float:none;display:inline;">> instance.</span></span></div><div  style="clear:both;"><span  style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;"><br ></span></div><div  style="clear:both;">Hmm, I tried to implement a new **clang** builtins. Then I could use</div><div  style="clear:both;">the new builtin in C++ source code directly. And the library implementation</div><div  style="clear:both;">also use the clang builtins directly without including or declaring.</div><div  style="clear:both;"><br ></div><div  style="clear:both;">I guess the gap is that I mean **clang** builtins instead of **LLVM** intrinsics.</div><div  style="clear:both;"><span  style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;"><br ></span></div><blockquote  style="margin-right:0;margin-top:0;margin-bottom:0;"><div  style="clear:both;"><span  style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;">------------------------------------------------------------------</span></div><div  style="clear:both;"><span  style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;">From:David Blaikie <dblaikie@gmail.com></span></div><div  style="clear:both;"><span  style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;">Send Time:2021年4月26日(星期一) 23:36</span></div><div  style="clear:both;"><span  style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;">To:chuanqi.xcq <yedeng.yd@linux.alibaba.com></span></div><div  style="clear:both;"><span  style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;">Cc:llvm-dev@lists.llvm.org <llvm-dev@lists.llvm.org></span></div><div  style="clear:both;"><span  style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;">Subject:Re: [llvm-dev] What's the principle to add builtins in clang?</span></div><div  style="clear:both;"><span  style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;"><br ></span></div>On Sun, Apr 25, 2021 at 10:06 PM chuanqi.xcq<br ><yedeng.yd@linux.alibaba.com> wrote:<br >><br >> Hi,<br >><br >> > I'm not really following this bit about changing the language without<br >> > changing the standard document, or what builtins have to do with the<br >> > C++ standard - could you explain this in more/different words,<br >> > perhaps?<br >><br >> I mean the C++ users could use builtins in their source codes, Although this is not recommended.<br ><br >Ah, I think LLVM builtins aren't available to C++ source code by<br >default - we wrap them in C intrinsics when that's desirable, for<br >instance.<br ><br >> In fact, in some projects which need to change the compiler move from GCC to Clang, I find some uses for some builtins.<br >> My point is, although builtins are not part of the language standard, people could use the builtins in their code actually.<br >> In other words, if the compiler adds new builtins, the actually semantic space would be larger than the design space.<br >> That's what I said, we change the language in fact without changing the language standard documentation.<br >><br >> Thanks,<br >> Chuanqi<br >><br >> ------------------------------------------------------------------<br >> From:David Blaikie <dblaikie@gmail.com><br >> Send Time:2021年4月24日(星期六) 02:51<br >> To:chuanqi.xcq <yedeng.yd@linux.alibaba.com><br >> Cc:llvm-dev@lists.llvm.org <llvm-dev@lists.llvm.org><br >> Subject:Re: [llvm-dev] What's the principle to add builtins in clang?<br >><br >> On Fri, Apr 23, 2021 at 1:30 AM chuanqi.xcq via llvm-dev<br >> <llvm-dev@lists.llvm.org> wrote:<br >> ><br >> > Hi all,<br >> ><br >> > Background:<br >> >     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.<br >> >     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.<br >> >     For example (uses if-else for simplicity):<br >> > ```<br >> > coro foo() {<br >> >     %handle = call i8* @llvm.coro.id(...)<br >> >     ; some works<br >> >     if (...)<br >> >         call void @llvm.coro.destroy(%handle)<br >> >     else {<br >> >        other works<br >> >        call void @llvm.coro.destroy(%handle)<br >> >     }<br >> > }<br >> > ```<br >> >     And it would be elided.<br >> >     And if:<br >> > ```<br >> > coro foo() {<br >> >     %handle = call i8* @llvm.coro.id(...)<br >> >     ; some works<br >> >     if (%handle)<br >> >         call void @llvm.coro.destroy(%handle)<br >> > }<br >> > ```<br >> >    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:<br >> > ```<br >> > coro foo() {<br >> >     %handle = call i8* @llvm.coro.id(...)<br >> >     ; some works<br >> >     if (%handle)<br >> >         call void @llvm.coro.destroy(%handle)<br >> >     call void @__builtin_coro_dead(%handle)<br >> > }<br >> > ```<br >> >     And it would be elided now.<br >> ><br >> > Question:<br >> >     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.<br >> > 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<br >> > 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<br >> > 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.<br >><br >> I'm not really following this bit about changing the language without<br >> changing the standard document, or what builtins have to do with the<br >> C++ standard - could you explain this in more/different words,<br >> perhaps?<br >><br >> In general, builtins are a compiler implementation detail (nothing to<br >> do with the C++ standard) and adding them is a tradeoff like adding<br >> new instructions to LLVM IR (though builtins are lower cost than<br >> instructions, generally - they're easier to add and remove/aren't such<br >> a fundamental part of the IR): Does the new builtin or instruction<br >> pull its weight: Adding new features to the IR in either case comes at<br >> a cost of implementation complexity (now optimization passes need to<br >> know about these new features) and if the semantics can be expressed<br >> reasonably cleanly with existing IR features, that's preferable (or if<br >> the IR feature can be generalized in some way to maximize the value<br >> (make it more usable for a variety of problems people are having<br >> trouble solving without it) while minimizing the cost (if it<br >> generalizes well to something that is easy/reasonable for IR consumers<br >> to handle/matches concepts they're already modeling/etc))<br >><br >></blockquote><div ><br ></div></div>