<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 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-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;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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">Hi Chris, thanks for your feedback!<o:p></o:p></p>
<p class="MsoNormal">>> Could you provide a patch that updates the Clang extensions manual? <o:p></o:p></p>
<p class="MsoNormal">I updated Language Extensions in the patch (D73967 being proposed). Is that sufficient, or are you looking for more information there?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>> Make sure the promotion semantics follow that of the rest of C.<o:p></o:p></p>
<p class="MsoNormal">C usual promotions are quite harmful to these types, so they don’t participate unless otherwise forced to. For example:<o:p></o:p></p>
<p class="MsoNormal"><br>
SomeI7 + SomeI8 // Operation done at I8 size<o:p></o:p></p>
<p class="MsoNormal">SomeI7 + SomeChar // SomeChar goes through usual promotions, so the operation happens as an int.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The second case is necessary for consistency with the C language, the first because otherwise these types don’t end up being particularly useful. On things like an FPGA (or otherwise limited hardware), rounding up is absurdly expensive.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>> - Your comment on the patch that "Unfortunately, this results in arrays on these platforms having ‘padding’ bits, but sufficiently motivated code generation can repair this problem.” I’d pretty strongly recommend that you do *not* special
case things like this, because they have user observable behavior. Either you decide to round sizeof up to a power of two, or to the next byte, I don’t see any other reasonable alternative. If the array behavior is important, then rounding up to the next
byte and using an alignment of 1 would provide a reasonable approximation of dense arrays.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Ah, I apologize, it seems that you’re looking at my first attempt at this proposal. I realize that I put both links, but
<a href="https://reviews.llvm.org/D73967"><span style="color:#954F72">https://reviews.llvm.org/D73967</span></a> is the active one. We chose to do/propose the sizeof roundup.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>> - My recollection is that Clang provides non-power-of-two bit width semantics for large bitfields in certain cases (this was required for GCC compatibility) without promoting to larger types. It would be good to make sure this is consistent
with that.<o:p></o:p></p>
<p class="MsoNormal">I believe they are consistent with that, but if you have an example that you’d like to be particularly consistent with, I’d love to check.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>> - These things will end up being passed and returned as arguments, it is important to nail down the ABI implications. I’d recommend passing them as the next power of two size integer.<o:p></o:p></p>
<p class="MsoNormal">This is already the behavior of LLVM in my experience (round to the next power of 2). We currently just defer to the LLVM implementation.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">>> - What is the maximum N? If the ABI or other behavior is specified in terms of power of existing power of two integers, then it would be good to limit it to whatever maxint is for a target.<o:p></o:p></p>
<p class="MsoNormal">In the patch, our Max-N is llvm::IntegerType::MAX_INT_BITS. Our language proposal specifies an implementation defined limit, so we chose the max that LLVM can deal with.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-Erich<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Chris Lattner <clattner@nondot.org> <br>
<b>Sent:</b> Tuesday, February 4, 2020 9:04 AM<br>
<b>To:</b> Keane, Erich <erich.keane@intel.com><br>
<b>Cc:</b> Clang Dev <cfe-dev@lists.llvm.org><br>
<b>Subject:</b> Re: [cfe-dev] [RFC] Proposing an Extended Integer Type<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hi Erich,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This looks like really interesting work, and I think it would be great for Clang to support this. That said, this is a significant language extension, and I think it is important to nail down the corner cases. Could you provide a patch
that updates the Clang extensions manual? This would provide a good place to describe the details of the behavior.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">On the semantics of this, I’d recommend the following:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> - Make sure the promotion semantics follow that of the rest of C.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - I agree that zero padding and rounding in sizeof is the right way to go. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - Your comment on the patch that "Unfortunately, this results in arrays on these platforms having ‘padding’ bits, but sufficiently motivated code generation can repair this problem.” I’d pretty strongly recommend that you do *not* special
case things like this, because they have user observable behavior. Either you decide to round sizeof up to a power of two, or to the next byte, I don’t see any other reasonable alternative. If the array behavior is important, then rounding up to the next
byte and using an alignment of 1 would provide a reasonable approximation of dense arrays.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - My recollection is that Clang provides non-power-of-two bit width semantics for large bitfields in certain cases (this was required for GCC compatibility) without promoting to larger types. It would be good to make sure this is consistent
with that.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - These things will end up being passed and returned as arguments, it is important to nail down the ABI implications. I’d recommend passing them as the next power of two size integer.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - What is the maximum N? If the ABI or other behavior is specified in terms of power of existing power of two integers, then it would be good to limit it to whatever maxint is for a target.<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-Chris<o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Feb 4, 2020, at 7:09 AM, Keane, Erich via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">TL;DR: We're proposing _ExtInt(N), a type in C languages that represents llvm iN in the language.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Note: This functionality was proposed earlier this year in<span class="apple-converted-space"> </span><a href="https://reviews.llvm.org/D59105"><span style="color:#954F72">https://reviews.llvm.org/D59105</span></a><span class="apple-converted-space"> </span>.
Valuable feedback was received by Richard Smith that was considered and integrated into this RFC. In the meantime, we also have user experience with the predecessor of D5910 which we have built on. A updated review based on the extensive feedback by Richard
is here:<span class="apple-converted-space"> </span><a href="https://reviews.llvm.org/D73967"><span style="color:#954F72">https://reviews.llvm.org/D73967</span></a><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>
<div>
<p class="MsoNormal">Introduction/Motivation:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">LLVM-IR supports integers of non-power-of-2 bitwidth, in the iN syntax. Integers of non-power-of-two aren't particularly interesting or useful on most hardware, so much so that no language in Clang has been motivated to expose it before.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">However, in the case of FPGA hardware normal integer types where the full bitwidth isn't used, is extremely wasteful and has severe performance/space concerns. Because of this, Intel has introduced this functionality in the High Level
Synthesis compiler (<a href="https://www.intel.com/content/www/us/en/software/programmable/quartus-prime/hls-compiler.html"><span style="color:#954F72">https://www.intel.com/content/www/us/en/software/programmable/quartus-prime/hls-compiler.html</span></a>)
under the name "Arbitrary Precision Integer" (ap_int for short). This has been extremely useful and effective for our users, permitting them to optimize their storage and operation space on an architecture where both can be extremely expensive.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">We are proposing upstreaming a more palatable version of this to the community, in the form of this proposal and accompanying patch. We are proposing the syntax _ExtInt(N). We intend to propose this to the WG14 committee, and the underscore-capital
seems like the active direction for a WG14 paper's acceptance. An alternative that Richard Smith suggested on the initial review was __int(N), however we believe that is much less acceptable by WG14. We considered _Int, however _Int is used as an identifier
in libstdc++ and there is no good way to fall back to an identifier (since _Int(5) is indistinguishable from an unnamed initializer of a template type named _Int).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Extension Proposal Requirements:<span class="apple-converted-space"> </span><a href="http://clang.llvm.org/get_involved.html"><span style="color:#954F72">http://clang.llvm.org/get_involved.html</span></a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Below are the extension proposal requirements along with some discussion that we believe we sufficiently meet for acceptance to the Clang/LLVM project.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">1: Evidence of a significant user community: This is based on a number of factors, including an existing user community, the perceived likelihood that users would adopt such a feature if it were available, and any secondary effects that
come from, e.g., a library adopting the feature and providing benefits to its users.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Our current HLS product has a large number of users that program against the ap_int interface on a near daily basis. However, this type/set of types isn't useful for JUST FPGAs. Thanks to the architecture of LLVM, these types are useable
in normal C/C++. Using signed versions of these types can be used for loop bounds, which provides some input to the loop optimizers, potentially resulting in better code generation. Both signed and unsigned versions provide more context as to the important
bits of a variable, which the optimizers can use to provide better code.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Even absent that, the additional expressivity these types provide are advantageous in many situations.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2: A specific need to reside within the Clang tree: There are some extensions that would be better expressed as a separate tool, and should remain as separate tools even if they end up being hosted as part of the LLVM umbrella project.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">These types need to be part of the type system, so no other tool can provide an effective interface for these. A set of library types was considered, however these are unable to properly represent them with the same gaurantees that are
necessary for effective code generation.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">3: A specification: The specification must be sufficient to understand the design of the feature as well as interpret the meaning of specific examples. The specification should be detailed enough that another compiler vendor could implement
the feature.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">A more formal specification is provided in the review in the Language Extensions documentation. We intend this to evolve toward completeness as the review progresses.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">4: Representation within the appropriate governing organization: For extensions to a language governed by a standards committee (C, C++, OpenCL), the extension itself must have an active proposal and proponent within that committee and
have a reasonable chance of acceptance. Clang should drive the standard, not diverge from it. This criterion does not apply to all extensions, since some extensions fall outside of the realm of the standards bodies.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">It is our intent to propose these types to the WG14 standards committee, with Melanie Blower authoring and presenting the paper for acceptance to the C committee. Said paper is available here:<span class="apple-converted-space"> </span><a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2472.pdf"><span style="color:#954F72">http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2472.pdf</span></a>.
Additionally, there is an active effort to propose these types to the SYCL standards committee.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">5: A long-term support plan: increasingly large or complex extensions to Clang need matching commitments to supporting them over time, including improving their implementation and specification as Clang evolves. The capacity of the contributor
to make that commitment is as important as the commitment itself.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">It is our intent to move our current customers to these new types (from a predecessor of the D59105 version), so this will be a long-term feature we intend to maintain in the clang code base. Additionally, these types will likely be well
used in SYCL, an actively used and maintained clang compiler language (currently maintained out of tree, with active effort to bring in-tree). Finally, contributor Erich Keane (the author of both D59105 as well as the patch accompanying this RFC) will be
providing time, effort, and experience to the continued maintenance of these types in the clang codebase. Additionally, we will be evolving both the implementation and specification along with the standardization efforts in WG14 and SYCL.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">6: A high-quality implementation: The implementation must fit well into Clang's architecture, follow LLVM's coding conventions, and meet Clang's quality standards, including diagnostics and complete AST representations. This is particularly
important for language extensions, because users will learn how those extensions work through the behavior of the compiler.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">It is our belief that the accompanying patch provided under review comes very close to meeting this criteria, and are confident that it will meet this criteria after community review.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">7: A test suite: Extensive testing is crucial to ensure that the language extension is not broken by ongoing maintenance in Clang. The test suite should be complete enough that another compiler vendor could conceivably validate their implementation
of the feature against it.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">The accompanying patch provides extensive semantic analysis LIT tests that we anticipate will be an effective test suite for other implementers. Additionally the patch has a large coverage of IR-CodeGen tests that should prevent further
breakage inside the clang codebase. We anticipate that the review process and ongoing maintenance of these types will further increase the test coverage of for these types.<o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">_______________________________________________<br>
cfe-dev mailing list<br>
</span><a href="mailto:cfe-dev@lists.llvm.org"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#954F72">cfe-dev@lists.llvm.org</span></a><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br>
</span><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:#954F72">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</span></a><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>