[cfe-dev] [RFC] Proposing an Extended Integer Type

[Keane, Erich 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 <jyknight at google.com>
Sent: Wednesday, February 5, 2020 7:19 AM
To: Keane, Erich <erich.keane at intel.com>
Cc: Chris Lattner <clattner at nondot.org>; Clang Dev <cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] [RFC] Proposing an Extended Integer Type



On Tue, Feb 4, 2020 at 12:14 PM Keane, Erich via cfe-dev <cfe-dev at lists.llvm.org<mailto:cfe-dev at lists.llvm.org>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200205/d8c1b4ea/attachment-0001.html>