<div class="gmail_quote">On Thu, Jan 5, 2012 at 1:24 AM, Umansky, Victor <span dir="ltr"><<a href="mailto:victor.umansky@intel.com">victor.umansky@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Answering Chandler’s questions:<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>1.<span style="font:7.0pt "Times New Roman"">     
</span></span></span><u></u><span dir="LTR"></span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">An 86 intrinsic prototype is defined by Intel together with the corresponding instruction, published in IA32 arch spec and
 in *intrin.h files. Consequently this prototype is accepted by all compiler providers – for compatibility reasons. The ptest* intrinsics return i32 type.</span></p></blockquote></div><div>I don't think we're talking about the same thing. There are two things called intrinsics here, and they're getting improperly conflated.</div>
<div><br></div><div>1) Intel (and other vendors) provide C intrinsics for accessing particular functionality in *intrin.h header files. This include _mm_testz_si128, and all kinds of others. They are *C* functions provided and implemented as part of the *C* compiler though. That's important.</div>
<div><br></div><div>2) LLVM defines LLVM intrinsic functions as part of the LLVM IR: <a href="http://llvm.org/docs/LangRef.html#intrinsics">http://llvm.org/docs/LangRef.html#intrinsics</a> and include/llvm/IntrinsicsX86.td are relevant for these. These are *not* C functions, and they cannot be called from C code directly. They are not a publicly visible interface.</div>
<div><br></div><div>Frontends such as Clang implement #1 by (roughly) emitting code which uses the intrinsics defined in #2.</div><div><br></div><div>Currently LLVM (#2) has intrinsics for PTEST which return an 'i32' even though the semantics of that instruction are best described by returning an 'i1' which can then directly be used in a 'br' instruction or a 'select' instruction. I'm suggesting changing *LLVM*'s intrinsic (#2) to return an 'i1'.</div>
<div><br></div><div>The frontend can then emit any adaptive logic necessary when lowering the interface of #1 (which remains the same, returning 'int') to code using LLVM's newly adapted intrinsics. Even if this requires "extra" or "redundant" IR, this should be optimized away *at the IR* level to preserve the generality of those optimizations, and because frankly optimizations on the IR are much easier to implement and maintain.</div>