<div dir="ltr">On Mon, Aug 19, 2013 at 2:39 PM, Morrison, Michael <span dir="ltr"><<a href="mailto:Michael_Morrison@playstation.sony.com" target="_blank">Michael_Morrison@playstation.sony.com</a>></span> wrote:<br><div class="gmail_extra">
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal">As some of you know, we at Sony Computer Entertainment America have been working on various aspects of LLVM, including Clang and its toolchain. As part of our work, we have created documentation for our customers about using Clang, and
we would like to share the fruits of our work with the Clang and LLVM communities.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">As our first documentation submission, we plan to provide our *CPU Intrinsics Guide*, which documents the Clang intrinsics for x86intrin.h, along with several builtin and sync types. I've included a sample of what we document for one of
the intrinsics below.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Our question for the community is: what documentation format is most helpful and desired for this information? We currently have two main possibilities in mind (with three variants for the first option):<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">1) Add the documentation for each intrinsic to the header file:<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">- 1a) Using Doxygen tagging. One benefit of this approach is that the documentation is available for the developer within a code-development/editing system. One potential difficulty with this approach is that the intrinsics header file
becomes much larger, which could increase compile times.</p></div></div></blockquote><div><br></div><div>Would you mind measuring this, at least approximately? If the performance penalty isn't substantial, I would lean towards this solution.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div>
<p class="MsoNormal">- 1b) Using Microsoft's annotation grammar. We might be able to contain this annotation grammar within Doxygen tagging that deviates somewhat from the LLVM Doxygen style. This approach allows us to generate XML output for the Microsoft
Visual Studio Tooltip class. The benefit of this approach is that the documentation is available for the developer within Visual Studio, without his or her having to open the specific header file. Like option (1a), one potential difficulty with this approach
is that the intrinsics header file becomes much larger, which could increase compile times.</p></div></div></blockquote><div><br></div><div>It's not clear to me why you can't generate XML output if you use LLVM Doxygen style; do you just not have a tool that can do the appropriate conversion?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div>
<p class="MsoNormal">- 1c) Using TblGen to maintain both the intrinsics definitions and their documentation, from which we generate the header file with both. With this approach, we could implement either option (1a), (1b), or both, and have a single point
of maintenance. This option has the same benefits and drawbacks as (1a) and (1b).</p></div></div></blockquote><div><br></div><div>Not really a fan of this; the intrinsics headers are hard enough to read without using some custom format.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div>
<p class="MsoNormal">2) Add the documentation in reST and Sphynx format (to match existing Clang and LLVM documentation) to the Clang Web site. The main benefit of this approach is that the documentation is available to anyone on the Web.</p>
</div></div></blockquote><div><br></div><div>If we have the docs in Doxygen format, we can convert them to HTML anyway.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<p class="MsoNormal">Thus, we come to you today to ask your opinion on which approach we should take. We're open to providing one or more of the formats, as desired, or considering a different option that one of you might make.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Sample intrinsic documentation (ASCII formatted for forum viewing)<u></u><u></u></p>
<p class="MsoNormal">-------------------------------<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">_mm256_round_ps<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">SYNOPSIS<u></u><u></u></p>
<p class="MsoNormal">#include <x86intrin.h><u></u><u></u></p>
<p class="MsoNormal">__m256 _mm256_round_ps(__m256 v, const int m);<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">INSTRUCTION<u></u><u></u></p>
<p class="MsoNormal">VROUNDPS<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">DESCRIPTION<u></u><u></u></p>
<p class="MsoNormal">Rounds the values stored in a packed 256-bit vector [8 x float] as specified by the byte operand. The source values are rounded to integer values and returned as floating point values.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">PARAMETERS<u></u><u></u></p>
<p class="MsoNormal">v A 256-bit vector of [8 x float] values.<u></u><u></u></p>
<p class="MsoNormal">m An immediate byte operand specifying how the rounding is to be performed.<u></u><u></u></p>
<p class="MsoNormal"> Bits [7:4] are reserved.<u></u><u></u></p>
<p class="MsoNormal"> Bit [3] is a precision exception value:<u></u><u></u></p>
<p class="MsoNormal"> 0: A normal PE exception is used<u></u><u></u></p>
<p class="MsoNormal"> 1: The PE field is not updated<u></u><u></u></p>
<p class="MsoNormal"> Bit [2] is a rounding control source:<u></u><u></u></p>
<p class="MsoNormal"> 0: MXCSR:RC<u></u><u></u></p>
<p class="MsoNormal"> 1: Use the RC field value<u></u><u></u></p>
<p class="MsoNormal"> Bit [1:0] contain the rounding control definition:<u></u><u></u></p>
<p class="MsoNormal"> 00: Nearest<u></u><u></u></p>
<p class="MsoNormal"> 01: Downward (toward negative infinity)<u></u><u></u></p>
<p class="MsoNormal"> 10: Upward (toward positive infinity)<u></u><u></u></p>
<p class="MsoNormal"> 11: Truncated<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">RETURNS<u></u><u></u></p>
<p class="MsoNormal">A 256-bit vector of [8 x float] containing the rounded values.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">-------------------------------</p></div></blockquote><div><br></div><div>Very nice. :)</div><div><br></div><div>-Eli </div></div></div></div>