<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 27, 2016 at 11:55 AM, James Knight via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div style="margin:0px;line-height:normal;color:rgb(35,35,35)">(Q: what about the implementation of __atomic_is_lock_free/__atomic_always_lock_free in clang? The clang frontend can't query target information from the llvm backend, can it? Is there some other way to expose the information of what sizes are supported by a backend so that the clang builtins -- the latter of which must be a C++ constant expression -- can also use it? Or...just continue duplicating the info in both places, as is done today...)</div></div></blockquote><div><br></div><div>I think this here is the main challenge. The frontend (and std::atomic implementations) need to know whether the target can perform an atomic operation without locks, and they can't rely on the LLVM target being built in for this information.</div><div><br></div><div>I think Clang should continue to duplicate this information, the same way we duplicate target datalayout strings. Other than that, sure, we can let LLVM expand IR operations to libcalls. I don't immediately see a problem with that.</div></div></div></div>