<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, sure - your initial email example/code snippets looked like LLVM</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;">> intrinsics to me (the @ and the . in names, etc). (& I might've</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;">> muddled up the intrinsics/builtins terminology)</span></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;"></span><br ></span></div><div  style="clear:both;"><span  style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;">Sorry for confusing. My intuition was to use pseudo IR (including if for simplicity).</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;"><span  style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;">Thanks,</span></div><div  style="clear:both;"><span  style="font-family:Tahoma,Arial,STHeiti,SimSun;font-size:14.0px;color:#000000;">Chuanqi</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;"><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月27日(星期二) 10:05</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 Mon, Apr 26, 2021 at 7:01 PM chuanqi.xcq <yedeng.yd@linux.alibaba.com> wrote:<br >><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 >> Hmm, I tried to implement a new **clang** builtins. Then I could use<br >> the new builtin in C++ source code directly. And the library implementation<br >> also use the clang builtins directly without including or declaring.<br >><br >> I guess the gap is that I mean **clang** builtins instead of **LLVM** intrinsics.<br ><br >Ah, sure - your initial email example/code snippets looked like LLVM<br >intrinsics to me (the @ and the . in names, etc). (& I might've<br >muddled up the intrinsics/builtins terminology)<br ><br >- Dave<br ><br >><br >> ------------------------------------------------------------------<br >> From:David Blaikie <dblaikie@gmail.com><br >> Send Time:2021年4月26日(星期一) 23:36<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 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 >> ><br >><br >></blockquote><div ><br ></div></div>