<div dir="ltr"><div dir="ltr">On Wed, 5 Feb 2020 at 15:36, Chris Lattner 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 style="overflow-wrap: break-word;"><br><div><br><blockquote type="cite"><div>On Feb 5, 2020, at 7:23 AM, Keane, Erich <<a href="mailto:erich.keane@intel.com" target="_blank">erich.keane@intel.com</a>> wrote:</div><br><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div style="margin:0in 0in 0.0001pt 0.5in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">>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.<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif">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.<u></u><u></u></div><div style="margin:0in 0in 0.0001pt;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div></div></div></blockquote><br></div><div>C’s promotion rules are unfortunate for almost everything :-).  </div><div><br></div><div>I think there are two reasonable paths here:</div><div><br></div><div>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.</div><div><br></div><div>2) Go for strict equivalent with no promotion rules, requiring everything to be explicit.</div><div><br></div><div>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.</div><div><br></div><div>WDYT?</div></div></blockquote><div><br></div><div>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.</div><div>Using the C rules for mixed _ExtInt / standard integer type calculations seems like it may be reasonable.</div></div></div>