<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 07/06/2017 10:41 AM, Bruce Hoult
wrote:<br>
</div>
<blockquote
cite="mid:CAMU+Ekx52Vc7MXG5ZLaT8ZzHUFtCspB+fsSGxy8P1=2dC7owfw@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">According to <a moz-do-not-send="true"
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>
</blockquote>
<br>
That might be true, but C++ does not have the implementation-defined
signal part. So whatever we did would need to be C specific at this
point.<br>
<br>
-Hal<br>
<br>
<blockquote
cite="mid:CAMU+Ekx52Vc7MXG5ZLaT8ZzHUFtCspB+fsSGxy8P1=2dC7owfw@mail.gmail.com"
type="cite">
<div dir="ltr">
<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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a
moz-do-not-send="true"
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
moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a
moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a moz-do-not-send="true"
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>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory</pre>
</body>
</html>