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

[Keane, Erich 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 <clattner at nondot.org> 
Sent: Friday, February 7, 2020 9:35 AM
To: Aaron Ballman <aaron at aaronballman.com>
Cc: Keane, Erich <erich.keane at intel.com>; richard at metafoo.co.uk; Clang Dev <cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] [RFC] Proposing an Extended Integer Type



> On Feb 6, 2020, at 6:22 AM, Aaron Ballman <aaron at aaronballman.com> wrote:
> 
> On Thu, Feb 6, 2020 at 9:12 AM Keane, Erich via cfe-dev 
> <cfe-dev at lists.llvm.org> 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 <richard at metafoo.co.uk>
>> Sent: Wednesday, February 5, 2020 6:02 PM
>> To: Chris Lattner <clattner at nondot.org>
>> Cc: Keane, Erich <erich.keane at intel.com>; Clang Dev 
>> <cfe-dev at lists.llvm.org>
>> Subject: Re: [cfe-dev] [RFC] Proposing an Extended Integer Type
>> 
>> 
>> 
>> On Wed, 5 Feb 2020 at 15:36, Chris Lattner via cfe-dev <cfe-dev at lists.llvm.org> wrote:
>> 
>> 
>> 
>> 
>> 
>> On Feb 5, 2020, at 7:23 AM, Keane, Erich <erich.keane at intel.com> 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
>> cfe-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev