[cfe-dev] [RFC] Proposing an Extended Integer Type
Keane, Erich via cfe-dev
cfe-dev at lists.llvm.org
Tue Feb 4 07:09:15 PST 2020
TL;DR: We're proposing _ExtInt(N), a type in C languages that represents llvm iN in the language.
Note: This functionality was proposed earlier this year in https://reviews.llvm.org/D59105 . 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: https://reviews.llvm.org/D73967
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.
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 (https://www.intel.com/content/www/us/en/software/programmable/quartus-prime/hls-compiler.html) 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.
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).
Extension Proposal Requirements: http://clang.llvm.org/get_involved.html
Below are the extension proposal requirements along with some discussion that we believe we sufficiently meet for acceptance to the Clang/LLVM project.
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.
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.
Even absent that, the additional expressivity these types provide are advantageous in many situations.
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.
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.
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.
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.
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.
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: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2472.pdf. Additionally, there is an active effort to propose these types to the SYCL standards committee.
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.
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.
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.
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.
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev