[RFC] Proposing an Extended Integer Type

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

[RFC] Proposing an Extended Integer Type

Hans Wennborg via cfe-dev

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

 

 

Introduction/Motivation:

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.


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Proposing an Extended Integer Type

Hans Wennborg via cfe-dev
Hi Erich,

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.

On the semantics of this, I’d recommend the following:

 - Make sure the promotion semantics follow that of the rest of C.
 - I agree that zero padding and rounding in sizeof is the right way to go.  
 - 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.
 - 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.
 - 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.
 - 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.

-Chris

On Feb 4, 2020, at 7:09 AM, Keane, Erich via cfe-dev <[hidden email]> wrote:

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
 
 
Introduction/Motivation:
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.
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Proposing an Extended Integer Type

Hans Wennborg via cfe-dev

Hi Chris, thanks for your feedback!

>> Could you provide a patch that updates the Clang extensions manual?  

I updated Language Extensions in the patch (D73967 being proposed).  Is that sufficient, or are you looking for more information there?

 

>> Make sure the promotion semantics follow that of the rest of C.

C usual promotions are quite harmful to these types, so they don’t participate unless otherwise forced to.  For example:


SomeI7 + SomeI8   // Operation done at I8 size

SomeI7 + SomeChar // SomeChar goes through usual promotions, so the operation happens as an int.

 

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.

 

>> - 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.

 

Ah, I apologize, it seems that you’re looking at my first attempt at this proposal.  I realize that I put both links, but https://reviews.llvm.org/D73967 is the active one.  We chose to do/propose the sizeof roundup.

 

>>  - 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.

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.

 

>>  - 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.

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.

 

>> - 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.

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.

 

-Erich

 

From: Chris Lattner <[hidden email]>
Sent: Tuesday, February 4, 2020 9:04 AM
To: Keane, Erich <[hidden email]>
Cc: Clang Dev <[hidden email]>
Subject: Re: [cfe-dev] [RFC] Proposing an Extended Integer Type

 

Hi Erich,

 

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.

 

On the semantics of this, I’d recommend the following:

 

 - Make sure the promotion semantics follow that of the rest of C.

 - I agree that zero padding and rounding in sizeof is the right way to go.  

 - 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.

 - 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.

 - 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.

 - 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.

 

-Chris



On Feb 4, 2020, at 7:09 AM, Keane, Erich via cfe-dev <[hidden email]> wrote:

 

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

 

 

Introduction/Motivation:

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.

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

 


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Proposing an Extended Integer Type

Hans Wennborg via cfe-dev


On Tue, Feb 4, 2020 at 12:14 PM Keane, Erich via cfe-dev <[hidden email]> wrote:

Hi Chris, thanks for your feedback!

>> Could you provide a patch that updates the Clang extensions manual?  

I updated Language Extensions in the patch (D73967 being proposed).  Is that sufficient, or are you looking for more information there?

 

>> Make sure the promotion semantics follow that of the rest of C.

C usual promotions are quite harmful to these types, so they don’t participate unless otherwise forced to.  For example:


SomeI7 + SomeI8   // Operation done at I8 size

SomeI7 + SomeChar // SomeChar goes through usual promotions, so the operation happens as an int.

 

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.


The first case seems unfortunate/inconsistent -- are you sure it's necessary to do that? When dealing with temporary values in an expression, LLVM should be able to determine that most of the bits aren't useful, and optimize based upon that. I'd expect that to be generally sufficient for handling the usual-int-promotion temporary values inside of an expression.

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Proposing an Extended Integer Type

Hans Wennborg via cfe-dev

 

>The first case seems unfortunate/inconsistent -- are you sure it's necessary to do that? When dealing with temporary values in an expression, LLVM should be able to determine that most of the bits aren't useful, and optimize based upon that. I'd expect that to be generally sufficient for handling the usual-int-promotion temporary values inside of an expression.

 

We found that it wasn’t the case in many cases (particularly in compound cases where intermediate values get large), which is incredibly expensive on some platforms.  Additionally, it heavily discourages the use of ‘auto’, which is otherwise incredibly useful for these types.

 

 

From: James Y Knight <[hidden email]>
Sent: Wednesday, February 5, 2020 7:19 AM
To: Keane, Erich <[hidden email]>
Cc: Chris Lattner <[hidden email]>; Clang Dev <[hidden email]>
Subject: Re: [cfe-dev] [RFC] Proposing an Extended Integer Type

 

 

 

On Tue, Feb 4, 2020 at 12:14 PM Keane, Erich via cfe-dev <[hidden email]> wrote:

Hi Chris, thanks for your feedback!

>> Could you provide a patch that updates the Clang extensions manual?  

I updated Language Extensions in the patch (D73967 being proposed).  Is that sufficient, or are you looking for more information there?

 

>> Make sure the promotion semantics follow that of the rest of C.

C usual promotions are quite harmful to these types, so they don’t participate unless otherwise forced to.  For example:


SomeI7 + SomeI8   // Operation done at I8 size

SomeI7 + SomeChar // SomeChar goes through usual promotions, so the operation happens as an int.

 

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.

 

The first case seems unfortunate/inconsistent -- are you sure it's necessary to do that? When dealing with temporary values in an expression, LLVM should be able to determine that most of the bits aren't useful, and optimize based upon that. I'd expect that to be generally sufficient for handling the usual-int-promotion temporary values inside of an expression.


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Proposing an Extended Integer Type

Hans Wennborg via cfe-dev


On Feb 5, 2020, at 7:23 AM, Keane, Erich <[hidden email]> wrote:

 
>The first case seems unfortunate/inconsistent -- are you sure it's necessary to do that? When dealing with temporary values in an expression, LLVM should be able to determine that most of the bits aren't useful, and optimize based upon that. I'd expect that to be generally sufficient for handling the usual-int-promotion temporary values inside of an expression.
 
We found that it wasn’t the case in many cases (particularly in compound cases where intermediate values get large), which is incredibly expensive on some platforms.  Additionally, it heavily discourages the use of ‘auto’, which is otherwise incredibly useful for these types.
 

C’s promotion rules are unfortunate for almost everything :-).  

I think there are two reasonable paths here:

1) Go for consistency with C and do the promotions, relying on the optimizer to trim them out.  You’ll want a suite of narrowing optimizations in any case.

2) Go for strict equivalent with no promotion rules, requiring everything to be explicit.

I agree with you that promotions are extremely extensive for FPGAs and the entire point of using this extension is to control widths.  If so, I think that argues for approach #2, which means that “int7 + int8” should be a compile time error, and that “int8” should be semantically different (but explicitly convertible) to other types like char that happen to have the same width.

WDYT?

-Chris


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Proposing an Extended Integer Type

Hans Wennborg via cfe-dev
On Wed, 5 Feb 2020 at 15:36, Chris Lattner via cfe-dev <[hidden email]> wrote:


On Feb 5, 2020, at 7:23 AM, Keane, Erich <[hidden email]> wrote:

 
>The first case seems unfortunate/inconsistent -- are you sure it's necessary to do that? When dealing with temporary values in an expression, LLVM should be able to determine that most of the bits aren't useful, and optimize based upon that. I'd expect that to be generally sufficient for handling the usual-int-promotion temporary values inside of an expression.
 
We found that it wasn’t the case in many cases (particularly in compound cases where intermediate values get large), which is incredibly expensive on some platforms.  Additionally, it heavily discourages the use of ‘auto’, which is otherwise incredibly useful for these types.
 

C’s promotion rules are unfortunate for almost everything :-).  

I think there are two reasonable paths here:

1) Go for consistency with C and do the promotions, relying on the optimizer to trim them out.  You’ll want a suite of narrowing optimizations in any case.

2) Go for strict equivalent with no promotion rules, requiring everything to be explicit.

I agree with you that promotions are extremely extensive for FPGAs and the entire point of using this extension is to control widths.  If so, I think that argues for approach #2, which means that “int7 + int8” should be a compile time error, and that “int8” should be semantically different (but explicitly convertible) to other types like char that happen to have the same width.

WDYT?

I agree with going for option #2 for the time being. I also think this is the part of the proposed semantics that WG14 is most likely to request revisions to, so it seems reasonable to pick an option that rejects all cases whose semantics might reasonably be expected to change.
Using the C rules for mixed _ExtInt / standard integer type calculations seems like it may be reasonable.

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Proposing an Extended Integer Type

Hans Wennborg via cfe-dev
In reply to this post by Hans Wennborg via cfe-dev
On Tue, 4 Feb 2020 at 07:10, Keane, Erich via cfe-dev <[hidden email]> wrote:

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

 

 

Introduction/Motivation:

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.


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.

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Proposing an Extended Integer Type

Hans Wennborg via cfe-dev
In reply to this post by Hans Wennborg via cfe-dev
C’s promotion rules are unfortunate for almost everything :-). 

plus:
 
2) Go for strict equivalent with no promotion rules, requiring everything to be explicit.

suggest that we would have a significant number of users of _ExtInt with 32 or 64 bit width. I'd cheerfully replace uint64_t with _ExtInt(64) (or however it's spelled) everywhere.

I also know of an isa which would have loved a twelve bit integer as an argument to an intrinsic as the instruction itself did 12 bit wrapping arithmetic.

Thanks

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Proposing an Extended Integer Type

Hans Wennborg via cfe-dev
In reply to this post by Hans Wennborg via cfe-dev

Doing the promotions is an incredible performance hit unfortunately, so I’d like to push for #2.

 

However, I’m not sure why that means rejecting non-matching types?  I guess I would think it makes sense to reject mixing these with standard integer types (so extint32 + int is an error, or extint8 + char, etc), but I don’t really see the value/case for rejecting extint6 + extint7?  Is it simply what Richard says (reject something that WG14 might change), or is it a stronger case?

 

Thanks,
Erich

 

From: Richard Smith <[hidden email]>
Sent: Wednesday, February 5, 2020 6:02 PM
To: Chris Lattner <[hidden email]>
Cc: Keane, Erich <[hidden email]>; Clang Dev <[hidden email]>
Subject: Re: [cfe-dev] [RFC] Proposing an Extended Integer Type

 

On Wed, 5 Feb 2020 at 15:36, Chris Lattner via cfe-dev <[hidden email]> wrote:

 



On Feb 5, 2020, at 7:23 AM, Keane, Erich <[hidden email]> wrote:

 

 

>The first case seems unfortunate/inconsistent -- are you sure it's necessary to do that? When dealing with temporary values in an expression, LLVM should be able to determine that most of the bits aren't useful, and optimize based upon that. I'd expect that to be generally sufficient for handling the usual-int-promotion temporary values inside of an expression.

 

We found that it wasn’t the case in many cases (particularly in compound cases where intermediate values get large), which is incredibly expensive on some platforms.  Additionally, it heavily discourages the use of ‘auto’, which is otherwise incredibly useful for these types.

 

 

C’s promotion rules are unfortunate for almost everything :-).  

 

I think there are two reasonable paths here:

 

1) Go for consistency with C and do the promotions, relying on the optimizer to trim them out.  You’ll want a suite of narrowing optimizations in any case.

 

2) Go for strict equivalent with no promotion rules, requiring everything to be explicit.

 

I agree with you that promotions are extremely extensive for FPGAs and the entire point of using this extension is to control widths.  If so, I think that argues for approach #2, which means that “int7 + int8” should be a compile time error, and that “int8” should be semantically different (but explicitly convertible) to other types like char that happen to have the same width.

 

WDYT?

 

I agree with going for option #2 for the time being. I also think this is the part of the proposed semantics that WG14 is most likely to request revisions to, so it seems reasonable to pick an option that rejects all cases whose semantics might reasonably be expected to change.

Using the C rules for mixed _ExtInt / standard integer type calculations seems like it may be reasonable.


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Proposing an Extended Integer Type

Hans Wennborg via cfe-dev
On Thu, Feb 6, 2020 at 9:12 AM Keane, Erich via cfe-dev
<[hidden email]> wrote:
>
> Doing the promotions is an incredible performance hit unfortunately, so I’d like to push for #2.

I would also recommend going for Option #2, at least until WG14 has
had the opportunity to consider the design and provide early feedback.
However, WG14 also likes to standardize existing practice off the
strength of the implementation experience, so we do have wiggle room
to consciously pick a design that we feel is the correct model. Given
that the next WG14 meeting is at the end of March, I still think going
with Option #2 for the moment is a good idea -- there is a wider
degree of hardware representation on the committee than what our
community currently supports, which could provide insights that we're
not considering, and the more restrictive initial design is easier to
modify later.

~Aaron

>
>
>
> However, I’m not sure why that means rejecting non-matching types?  I guess I would think it makes sense to reject mixing these with standard integer types (so extint32 + int is an error, or extint8 + char, etc), but I don’t really see the value/case for rejecting extint6 + extint7?  Is it simply what Richard says (reject something that WG14 might change), or is it a stronger case?
>
>
>
> Thanks,
> Erich
>
>
>
> From: Richard Smith <[hidden email]>
> Sent: Wednesday, February 5, 2020 6:02 PM
> To: Chris Lattner <[hidden email]>
> Cc: Keane, Erich <[hidden email]>; Clang Dev <[hidden email]>
> Subject: Re: [cfe-dev] [RFC] Proposing an Extended Integer Type
>
>
>
> On Wed, 5 Feb 2020 at 15:36, Chris Lattner via cfe-dev <[hidden email]> wrote:
>
>
>
>
>
> On Feb 5, 2020, at 7:23 AM, Keane, Erich <[hidden email]> wrote:
>
>
>
>
>
> >The first case seems unfortunate/inconsistent -- are you sure it's necessary to do that? When dealing with temporary values in an expression, LLVM should be able to determine that most of the bits aren't useful, and optimize based upon that. I'd expect that to be generally sufficient for handling the usual-int-promotion temporary values inside of an expression.
>
>
>
> We found that it wasn’t the case in many cases (particularly in compound cases where intermediate values get large), which is incredibly expensive on some platforms.  Additionally, it heavily discourages the use of ‘auto’, which is otherwise incredibly useful for these types.
>
>
>
>
>
> C’s promotion rules are unfortunate for almost everything :-).
>
>
>
> I think there are two reasonable paths here:
>
>
>
> 1) Go for consistency with C and do the promotions, relying on the optimizer to trim them out.  You’ll want a suite of narrowing optimizations in any case.
>
>
>
> 2) Go for strict equivalent with no promotion rules, requiring everything to be explicit.
>
>
>
> I agree with you that promotions are extremely extensive for FPGAs and the entire point of using this extension is to control widths.  If so, I think that argues for approach #2, which means that “int7 + int8” should be a compile time error, and that “int8” should be semantically different (but explicitly convertible) to other types like char that happen to have the same width.
>
>
>
> WDYT?
>
>
>
> I agree with going for option #2 for the time being. I also think this is the part of the proposed semantics that WG14 is most likely to request revisions to, so it seems reasonable to pick an option that rejects all cases whose semantics might reasonably be expected to change.
>
> Using the C rules for mixed _ExtInt / standard integer type calculations seems like it may be reasonable.
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Proposing an Extended Integer Type

Hans Wennborg via cfe-dev


> On Feb 6, 2020, at 6:22 AM, Aaron Ballman <[hidden email]> wrote:
>
> On Thu, Feb 6, 2020 at 9:12 AM Keane, Erich via cfe-dev
> <[hidden email]> wrote:
>>
>> Doing the promotions is an incredible performance hit unfortunately, so I’d like to push for #2.
>
> I would also recommend going for Option #2, at least until WG14 has
> had the opportunity to consider the design and provide early feedback.

I agree that going with #2 makes the most sense for the initial implementation.  In addition to your arguments, it is also the most conservative design.  It is much easier to take a narrow design and expand it, than to take a wider design and narrowing it - because that leads to rejecting or changing the behavior of previously accepted code.

-Chris

> However, WG14 also likes to standardize existing practice off the
> strength of the implementation experience, so we do have wiggle room
> to consciously pick a design that we feel is the correct model. Given
> that the next WG14 meeting is at the end of March, I still think going
> with Option #2 for the moment is a good idea -- there is a wider
> degree of hardware representation on the committee than what our
> community currently supports, which could provide insights that we're
> not considering, and the more restrictive initial design is easier to
> modify later.
>
> ~Aaron
>
>>
>>
>>
>> However, I’m not sure why that means rejecting non-matching types?  I guess I would think it makes sense to reject mixing these with standard integer types (so extint32 + int is an error, or extint8 + char, etc), but I don’t really see the value/case for rejecting extint6 + extint7?  Is it simply what Richard says (reject something that WG14 might change), or is it a stronger case?
>>
>>
>>
>> Thanks,
>> Erich
>>
>>
>>
>> From: Richard Smith <[hidden email]>
>> Sent: Wednesday, February 5, 2020 6:02 PM
>> To: Chris Lattner <[hidden email]>
>> Cc: Keane, Erich <[hidden email]>; Clang Dev <[hidden email]>
>> Subject: Re: [cfe-dev] [RFC] Proposing an Extended Integer Type
>>
>>
>>
>> On Wed, 5 Feb 2020 at 15:36, Chris Lattner via cfe-dev <[hidden email]> wrote:
>>
>>
>>
>>
>>
>> On Feb 5, 2020, at 7:23 AM, Keane, Erich <[hidden email]> wrote:
>>
>>
>>
>>
>>
>>> The first case seems unfortunate/inconsistent -- are you sure it's necessary to do that? When dealing with temporary values in an expression, LLVM should be able to determine that most of the bits aren't useful, and optimize based upon that. I'd expect that to be generally sufficient for handling the usual-int-promotion temporary values inside of an expression.
>>
>>
>>
>> We found that it wasn’t the case in many cases (particularly in compound cases where intermediate values get large), which is incredibly expensive on some platforms.  Additionally, it heavily discourages the use of ‘auto’, which is otherwise incredibly useful for these types.
>>
>>
>>
>>
>>
>> C’s promotion rules are unfortunate for almost everything :-).
>>
>>
>>
>> I think there are two reasonable paths here:
>>
>>
>>
>> 1) Go for consistency with C and do the promotions, relying on the optimizer to trim them out.  You’ll want a suite of narrowing optimizations in any case.
>>
>>
>>
>> 2) Go for strict equivalent with no promotion rules, requiring everything to be explicit.
>>
>>
>>
>> I agree with you that promotions are extremely extensive for FPGAs and the entire point of using this extension is to control widths.  If so, I think that argues for approach #2, which means that “int7 + int8” should be a compile time error, and that “int8” should be semantically different (but explicitly convertible) to other types like char that happen to have the same width.
>>
>>
>>
>> WDYT?
>>
>>
>>
>> I agree with going for option #2 for the time being. I also think this is the part of the proposed semantics that WG14 is most likely to request revisions to, so it seems reasonable to pick an option that rejects all cases whose semantics might reasonably be expected to change.
>>
>> Using the C rules for mixed _ExtInt / standard integer type calculations seems like it may be reasonable.
>>
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Proposing an Extended Integer Type

Hans Wennborg via cfe-dev
Alright, I can do that.  Limiting to no mixed operations involving Ext-int is disappointingly limiting, but since we expose it via a library I believe we can work around that.  Hopefully WG14 sees the 'light' in March and we can relax this rule later.

I intend to get the patch to do so up as soon as I can, though it'll likely be a while since I'm off to the WG21 meeting tomorrow.

Thanks!
Erich

-----Original Message-----
From: Chris Lattner <[hidden email]>
Sent: Friday, February 7, 2020 9:35 AM
To: Aaron Ballman <[hidden email]>
Cc: Keane, Erich <[hidden email]>; [hidden email]; Clang Dev <[hidden email]>
Subject: Re: [cfe-dev] [RFC] Proposing an Extended Integer Type



> On Feb 6, 2020, at 6:22 AM, Aaron Ballman <[hidden email]> wrote:
>
> On Thu, Feb 6, 2020 at 9:12 AM Keane, Erich via cfe-dev
> <[hidden email]> wrote:
>>
>> Doing the promotions is an incredible performance hit unfortunately, so I’d like to push for #2.
>
> I would also recommend going for Option #2, at least until WG14 has
> had the opportunity to consider the design and provide early feedback.

I agree that going with #2 makes the most sense for the initial implementation.  In addition to your arguments, it is also the most conservative design.  It is much easier to take a narrow design and expand it, than to take a wider design and narrowing it - because that leads to rejecting or changing the behavior of previously accepted code.

-Chris

> However, WG14 also likes to standardize existing practice off the
> strength of the implementation experience, so we do have wiggle room
> to consciously pick a design that we feel is the correct model. Given
> that the next WG14 meeting is at the end of March, I still think going
> with Option #2 for the moment is a good idea -- there is a wider
> degree of hardware representation on the committee than what our
> community currently supports, which could provide insights that we're
> not considering, and the more restrictive initial design is easier to
> modify later.
>
> ~Aaron
>
>>
>>
>>
>> However, I’m not sure why that means rejecting non-matching types?  I guess I would think it makes sense to reject mixing these with standard integer types (so extint32 + int is an error, or extint8 + char, etc), but I don’t really see the value/case for rejecting extint6 + extint7?  Is it simply what Richard says (reject something that WG14 might change), or is it a stronger case?
>>
>>
>>
>> Thanks,
>> Erich
>>
>>
>>
>> From: Richard Smith <[hidden email]>
>> Sent: Wednesday, February 5, 2020 6:02 PM
>> To: Chris Lattner <[hidden email]>
>> Cc: Keane, Erich <[hidden email]>; Clang Dev
>> <[hidden email]>
>> Subject: Re: [cfe-dev] [RFC] Proposing an Extended Integer Type
>>
>>
>>
>> On Wed, 5 Feb 2020 at 15:36, Chris Lattner via cfe-dev <[hidden email]> wrote:
>>
>>
>>
>>
>>
>> On Feb 5, 2020, at 7:23 AM, Keane, Erich <[hidden email]> wrote:
>>
>>
>>
>>
>>
>>> The first case seems unfortunate/inconsistent -- are you sure it's necessary to do that? When dealing with temporary values in an expression, LLVM should be able to determine that most of the bits aren't useful, and optimize based upon that. I'd expect that to be generally sufficient for handling the usual-int-promotion temporary values inside of an expression.
>>
>>
>>
>> We found that it wasn’t the case in many cases (particularly in compound cases where intermediate values get large), which is incredibly expensive on some platforms.  Additionally, it heavily discourages the use of ‘auto’, which is otherwise incredibly useful for these types.
>>
>>
>>
>>
>>
>> C’s promotion rules are unfortunate for almost everything :-).
>>
>>
>>
>> I think there are two reasonable paths here:
>>
>>
>>
>> 1) Go for consistency with C and do the promotions, relying on the optimizer to trim them out.  You’ll want a suite of narrowing optimizations in any case.
>>
>>
>>
>> 2) Go for strict equivalent with no promotion rules, requiring everything to be explicit.
>>
>>
>>
>> I agree with you that promotions are extremely extensive for FPGAs and the entire point of using this extension is to control widths.  If so, I think that argues for approach #2, which means that “int7 + int8” should be a compile time error, and that “int8” should be semantically different (but explicitly convertible) to other types like char that happen to have the same width.
>>
>>
>>
>> WDYT?
>>
>>
>>
>> I agree with going for option #2 for the time being. I also think this is the part of the proposed semantics that WG14 is most likely to request revisions to, so it seems reasonable to pick an option that rejects all cases whose semantics might reasonably be expected to change.
>>
>> Using the C rules for mixed _ExtInt / standard integer type calculations seems like it may be reasonable.
>>
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: [RFC] Proposing an Extended Integer Type

Hans Wennborg via cfe-dev
Thanks Erich!

-Chris

> On Feb 7, 2020, at 9:42 AM, Keane, Erich <[hidden email]> wrote:
>
> Alright, I can do that.  Limiting to no mixed operations involving Ext-int is disappointingly limiting, but since we expose it via a library I believe we can work around that.  Hopefully WG14 sees the 'light' in March and we can relax this rule later.
>
> I intend to get the patch to do so up as soon as I can, though it'll likely be a while since I'm off to the WG21 meeting tomorrow.
>
> Thanks!
> Erich
>
> -----Original Message-----
> From: Chris Lattner <[hidden email]>
> Sent: Friday, February 7, 2020 9:35 AM
> To: Aaron Ballman <[hidden email]>
> Cc: Keane, Erich <[hidden email]>; [hidden email]; Clang Dev <[hidden email]>
> Subject: Re: [cfe-dev] [RFC] Proposing an Extended Integer Type
>
>
>
>> On Feb 6, 2020, at 6:22 AM, Aaron Ballman <[hidden email]> wrote:
>>
>> On Thu, Feb 6, 2020 at 9:12 AM Keane, Erich via cfe-dev
>> <[hidden email]> wrote:
>>>
>>> Doing the promotions is an incredible performance hit unfortunately, so I’d like to push for #2.
>>
>> I would also recommend going for Option #2, at least until WG14 has
>> had the opportunity to consider the design and provide early feedback.
>
> I agree that going with #2 makes the most sense for the initial implementation.  In addition to your arguments, it is also the most conservative design.  It is much easier to take a narrow design and expand it, than to take a wider design and narrowing it - because that leads to rejecting or changing the behavior of previously accepted code.
>
> -Chris
>
>> However, WG14 also likes to standardize existing practice off the
>> strength of the implementation experience, so we do have wiggle room
>> to consciously pick a design that we feel is the correct model. Given
>> that the next WG14 meeting is at the end of March, I still think going
>> with Option #2 for the moment is a good idea -- there is a wider
>> degree of hardware representation on the committee than what our
>> community currently supports, which could provide insights that we're
>> not considering, and the more restrictive initial design is easier to
>> modify later.
>>
>> ~Aaron
>>
>>>
>>>
>>>
>>> However, I’m not sure why that means rejecting non-matching types?  I guess I would think it makes sense to reject mixing these with standard integer types (so extint32 + int is an error, or extint8 + char, etc), but I don’t really see the value/case for rejecting extint6 + extint7?  Is it simply what Richard says (reject something that WG14 might change), or is it a stronger case?
>>>
>>>
>>>
>>> Thanks,
>>> Erich
>>>
>>>
>>>
>>> From: Richard Smith <[hidden email]>
>>> Sent: Wednesday, February 5, 2020 6:02 PM
>>> To: Chris Lattner <[hidden email]>
>>> Cc: Keane, Erich <[hidden email]>; Clang Dev
>>> <[hidden email]>
>>> Subject: Re: [cfe-dev] [RFC] Proposing an Extended Integer Type
>>>
>>>
>>>
>>> On Wed, 5 Feb 2020 at 15:36, Chris Lattner via cfe-dev <[hidden email]> wrote:
>>>
>>>
>>>
>>>
>>>
>>> On Feb 5, 2020, at 7:23 AM, Keane, Erich <[hidden email]> wrote:
>>>
>>>
>>>
>>>
>>>
>>>> The first case seems unfortunate/inconsistent -- are you sure it's necessary to do that? When dealing with temporary values in an expression, LLVM should be able to determine that most of the bits aren't useful, and optimize based upon that. I'd expect that to be generally sufficient for handling the usual-int-promotion temporary values inside of an expression.
>>>
>>>
>>>
>>> We found that it wasn’t the case in many cases (particularly in compound cases where intermediate values get large), which is incredibly expensive on some platforms.  Additionally, it heavily discourages the use of ‘auto’, which is otherwise incredibly useful for these types.
>>>
>>>
>>>
>>>
>>>
>>> C’s promotion rules are unfortunate for almost everything :-).
>>>
>>>
>>>
>>> I think there are two reasonable paths here:
>>>
>>>
>>>
>>> 1) Go for consistency with C and do the promotions, relying on the optimizer to trim them out.  You’ll want a suite of narrowing optimizations in any case.
>>>
>>>
>>>
>>> 2) Go for strict equivalent with no promotion rules, requiring everything to be explicit.
>>>
>>>
>>>
>>> I agree with you that promotions are extremely extensive for FPGAs and the entire point of using this extension is to control widths.  If so, I think that argues for approach #2, which means that “int7 + int8” should be a compile time error, and that “int8” should be semantically different (but explicitly convertible) to other types like char that happen to have the same width.
>>>
>>>
>>>
>>> WDYT?
>>>
>>>
>>>
>>> I agree with going for option #2 for the time being. I also think this is the part of the proposed semantics that WG14 is most likely to request revisions to, so it seems reasonable to pick an option that rejects all cases whose semantics might reasonably be expected to change.
>>>
>>> Using the C rules for mixed _ExtInt / standard integer type calculations seems like it may be reasonable.
>>>
>>> _______________________________________________
>>> cfe-dev mailing list
>>> [hidden email]
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev