<div dir="ltr"><div dir="ltr">On Tue, 4 Feb 2020 at 07:10, Keane, Erich via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-US">
<div class="gmail-m_5274928222882404617WordSection1">
<p class="MsoNormal">TL;DR: We're proposing _ExtInt(N), a type in C languages that represents llvm iN in the language.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Note: This functionality was proposed earlier this year in <a href="https://reviews.llvm.org/D59105" target="_blank">https://reviews.llvm.org/D59105</a> . 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: <a href="https://reviews.llvm.org/D73967" target="_blank">https://reviews.llvm.org/D73967</a><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Introduction/Motivation:<u></u><u></u></p>
<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.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<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" target="_blank">https://www.intel.com/content/www/us/en/software/programmable/quartus-prime/hls-compiler.html</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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<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).<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Extension Proposal Requirements: <a href="http://clang.llvm.org/get_involved.html" target="_blank">http://clang.llvm.org/get_involved.html</a><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Even absent that, the additional expressivity these types provide are advantageous in many situations.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<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: <a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2472.pdf" target="_blank">http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2472.pdf</a>.
Additionally, there is an active effort to propose these types to the SYCL standards committee.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<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.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<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.</p></div></div></blockquote><div><br></div><div>Thanks, I'm satisfied by the above. I guess we'll need to wait and see what WG14 thinks about the naming question, but using _ExtInt in the mean time seems fine. More comments on the patch itself.</div></div></div>