<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">I don't know about the "public" contract, but Clang's own lzcntintrin.h uses __builtin_clz without a runtime zero check, protected
by the __LZCNT__ preprocessor define. So Clang's own headers are assuming that __builtin_clz will be treated as defined for zero input on these machines. That makes my patch a correctness fix, not 'just' an optimization.<o:p></o:p></span></a></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">If you use Clang's intrinsics (either the ones from Intrin.h or the ones from lzcntintrin.h) you shouldn't need to add your own zero checks; but that's the
public contract for the intrinsics, not the builtins.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">If we leave __builtin_clz defined as-is, you should always add your own zero check; on appropriate machines sometimes Clang will be able to tell and optimize
it away. But that's target-dependent and I don't know that it would be all that smart to codify that target-dependent behavior as part of the public contract.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--paulr<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Sean Silva [mailto:chisophugis@gmail.com]
<br>
<b>Sent:</b> Friday, October 24, 2014 5:46 PM<br>
<b>To:</b> Arthur O'Dwyer<br>
<b>Cc:</b> Robinson, Paul; cfe-commits@cs.uiuc.edu<br>
<b>Subject:</b> Re: [PATCH][X86] __builtin_ctz/clz sometimed defined for zero input<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On Fri, Oct 24, 2014 at 4:53 PM, Arthur O'Dwyer <<a href="mailto:arthur.j.odwyer@gmail.com" target="_blank">arthur.j.odwyer@gmail.com</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">On Fri, Oct 24, 2014 at 3:55 PM, Sean Silva <<a href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>> wrote:<br>
><br>
> What is the harm of documenting it? By defining this behavior we are<br>
> pledging to forever support it.<br>
<br>
Exactly. That's harm enough, isn't it?<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">It looks like clang already has precedent for doing this, and a corresponding infrastructure for doing so, so it shouldn't be too problematic.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><br>
<br>
>> This allows us to optimize<br>
>> unsigned foo(unsigned x) { return (x ? __builtin_clz(x) : 32) }<br>
>> into a single LZCNT instruction on a BMI-capable X86, if we choose.<br>
<br>
I'm no expert, but isn't this kind of peephole optimization supposed<br>
to be handled by the LLVM (backend) side of things, not the Clang<br>
side?<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">It's not an optimization that is being talked about here. It's a change of semantic meaning to define a previously undefined situation. Presumably it's a win for the user that thinks that __builtin_clz means "the best clz-like instruction
available for the target", rather than the independently defined meaning given in the docs.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">-- Sean Silva<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><br>
The behavior of __builtin_clz(0) is undefined, so no portable program<br>
can use it. Sure, it might happen to work on your machine, but then<br>
you switch to a different architecture, or even a slightly older x86,<br>
or a year from now Intel introduces an *even faster* bit-count<br>
instruction that yields the wrong value for 0... and suddenly your<br>
program breaks, and you have to waste time tracking down the bug.<br>
<br>
Therefore, portable programs WILL use<br>
<br>
unsigned foo(unsigned x) { return (x ? __builtin_clz(x) : 32) }<br>
<br>
Therefore, it would be awesome if the LLVM backend for these<br>
particular Intel x86 machines would generate the most-optimized LZCNT<br>
instruction sequence for "foo". This seems relatively easy and<br>
shouldn't involve any changes to the Clang front-end, and *certainly*<br>
not to the documentation.<br>
<br>
Then you get the best of both worlds — old portable code continues to<br>
work (but gets faster), and newly written code continues to be<br>
portable.<br>
<br>
Andrea wrote:<br>
>> > My concern is that your suggested approach would force people to<br>
>> > always guard calls to __builtin_ctz/__builtin_clz against zero.<br>
>> > From a customer point of view, the compiler knows exactly if ctz and<br>
>> > clz is defined on zero. It is basically pushing the problem on the<br>
>> > customer by forcing them to guard all the calls to ctz/clz against<br>
>> > zero. We've already had a number of customer queries/complaints about<br>
>> > this and I personally don't think it is unreasonable to have ctz/clz<br>
>> > defined on zero on our target (and other x86 targets where the<br>
>> > behavior on zero is clearly defined).<br>
<br>
Sounds like a good argument in favor of introducing a new builtin,<br>
spelled something like "__builtin_lzcnt", that does what the customer<br>
wants. It could be implemented internally as (x ? __builtin_clz(x) :<br>
32), and lowered to a single instruction if possible by the LLVM<br>
backend for your target.<br>
<br>
my $.02,<br>
–Arthur<o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>