<div dir="ltr">According to <a href="http://6.3.1.3/3">6.3.1.3/3</a> of the C standard (I didn't check C++):<div><br></div><div><div>"3 Otherwise, the new type is signed and the value cannot be represented in it; either the result is implementation-defined or an implementation-defined signal is raised."</div></div><div><br></div><div>I *think* that means that IF a signal is raised then the signal raised could be one that you can't guarantee to be able to return from ("SIGFPE, SIGILL, SIGSEGV, or any other implementation-defined value corresponding to a computational exception") and thus it is implementation defined whether the program will terminate.</div><div><br></div><div>That provides pretty big scope to optimize around :-)</div><div><br></div><div>Note also that while unsigned variables require the implementation to act AS IF running on a binary machine, signed variables have no such requirement. Most implementations do in fact truncate by taking the remainder modulus the number of values that can be represented in the destination type, but that might not be a power of two.</div><div><br></div><div>I would guess there is very little code in the wild that conforms to a strict interpretation of all this.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 6, 2017 at 5:24 PM, Alexandre Isoard via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Hal,<div><br></div><div>I just want to check I understand correctly the subtlety, in C++ an overflowing signed addition is an undefined behavior (so Clang adds the nsw keyword to the sign add), while a signed cast that overflow is "only" implementation defined (so Clang cant risk to produce poison on trunc). Is that right?</div><div><br></div><div>If trunc produced undef instead of poison, clang could use it, but then it is less useful and/or unwanted?</div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On Wed, Jul 5, 2017 at 10:30 PM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span>
<p><br>
</p>
<div class="m_-4031313276823298246m_5162489970081525388m_-3311001276389849401moz-cite-prefix">On 07/05/2017 03:10 PM, Alexandre
Isoard wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Ah, ok. I read it wrong. In *neither* case it is
UB.
<div><br>
</div>
<div>Hum, can an implementation define it as UB? :-)</div>
</div>
</blockquote>
<br></span>
Nope :-)<br>
<br>
The only case I've thought of where we could add these for C++ would
be on conversions to (most) enums (because they used signed
underlying types and the out-of-bounds mapping won't generally be
one of the allowed values (or maybe we can define this to be the
case?)).<span class="m_-4031313276823298246m_5162489970081525388HOEnZb"><font color="#888888"><br>
<br>
-Hal</font></span><div><div class="m_-4031313276823298246m_5162489970081525388h5"><br>
<br>
<blockquote type="cite">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Wed, Jul 5, 2017 at 9:09 PM,
Alexandre Isoard <span dir="ltr"><<a href="mailto:alexandre.isoard@gmail.com" target="_blank">alexandre.isoard@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote"><span>On Wed, Jul 5,
2017 at 3:59 PM, Hal Finkel via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><br>
On 07/04/2017 01:41 AM, Dr.-Ing. Christoph
Cullmann via llvm-dev wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Alexandre,<br>
<br>
LLVM currently doesn't have trunc nsw/nuw,
no.<br>
Which frontend would emit such instructions?
Any application in mind?<br>
Just asking because if no frontend could
emit those, then the motivation to<br>
add nsw/nuw support to trunc would be very
low I guess.<br>
</blockquote>
I think the clang frontend could use that to
allow better static analysis of integer
overflows<br>
on the LLVM IR.<br>
<br>
It might be interesting for static analysis
tools that want to know if you truncate
something<br>
that is too large for the target range but you
need the sign to determine, e.g. the C/C++
frontend<br>
could use that flag for trunc of
signed/unsigned integers, then you could e.g.
check if<br>
<br>
(uint8_t)x<br>
<br>
changes the values if x has stuff out of the
0..255 range.<br>
<br>
e.g. x as int with -100 => trunc nuw to 8
=> bad<br>
<br>
(int8_t)x<br>
<br>
=> trunc nsw to 8 => ok<br>
</blockquote>
<br>
</span>
I'm not sure that a C/C++ frontend could add this
flag. In C++, the conversion for unsigned types is
specified and for signed types, it's
implementation defined, but in neither case is it
UB.<br>
</blockquote>
<div><br>
</div>
</span>
<div>Hmm, I don't get it.</div>
<div><br>
</div>
<div>Two questions:</div>
<div>- if the conversion for unsigned types is
specified, how is it undefined behavior?</div>
<div>- if the conversion for signed types is UB, then
this is a direct application of those flags, isn't
it?</div>
<div>
<div class="m_-4031313276823298246m_5162489970081525388m_-3311001276389849401h5">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-Hal
<div>
<div class="m_-4031313276823298246m_5162489970081525388m_-3311001276389849401m_-5682808666156860653h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Greetings<br>
Christoph<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks,<br>
Nuno<br>
<br>
-----Original Message-----<br>
From: Alexandre Isoard via llvm-dev<br>
Sent: Monday, July 3, 2017 8:38 PM<br>
To: llvm-dev<br>
Subject: [llvm-dev] trunc nsw/nuw?<br>
<br>
<br>
Hello,<br>
<br>
From [1], trunc does not seems to have
a nsw/nuw attribute.<br>
Is it possible to have that? Or do we
have that and it is not up-to-date?<br>
<br>
The definition would be:<br>
<br>
If the nuw keyword is present, the
result value of the trunc is a poison<br>
value if the truncated high order bits
are non-zero. If the nsw keyword is<br>
present, the result value of the trunc
is a poison value if the truncated<br>
high order bits are not all equal to the
non-truncated bit of the highest<br>
order.<br>
<br>
This allow to cancel out:<br>
- sext with trunc nsw<br>
- zext with trunc nuw<br>
<br>
And probably to commute with
add/sub/mul/lshr/ashr/shl/urem<wbr>/udiv/udiv
(with<br>
the correct flags).<br>
<br>
[1]: <a href="http://llvm.org/docs/LangRef.html#trunc-to-instruction" rel="noreferrer" target="_blank">http://llvm.org/docs/LangRef.h<wbr>tml#trunc-to-instruction</a><br>
<br>
<br>
--<br>
<br>
Alexandre Isoard<br>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote>
</blockquote>
<br>
-- <br>
</div>
</div>
Hal Finkel<br>
Lead, Compiler Technology and Programming
Languages<br>
Leadership Computing Facility<br>
Argonne National Laboratory
<div class="m_-4031313276823298246m_5162489970081525388m_-3311001276389849401m_-5682808666156860653HOEnZb">
<div class="m_-4031313276823298246m_5162489970081525388m_-3311001276389849401m_-5682808666156860653h5"><br>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<span class="m_-4031313276823298246m_5162489970081525388m_-3311001276389849401HOEnZb"><font color="#888888"><br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="m_-4031313276823298246m_5162489970081525388m_-3311001276389849401m_-5682808666156860653gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr"><b>Alexandre Isoard</b><br>
</div>
</div>
</font></span></div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div class="m_-4031313276823298246m_5162489970081525388m_-3311001276389849401gmail_signature" data-smartmail="gmail_signature">
<div dir="ltr"><b>Alexandre Isoard</b><br>
</div>
</div>
</div>
</blockquote>
<br>
<pre class="m_-4031313276823298246m_5162489970081525388m_-3311001276389849401moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</div></div></div>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div class="m_-4031313276823298246m_5162489970081525388gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><b>Alexandre Isoard</b><br></div></div>
</font></span></div></div>
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>