<div dir="ltr">Hi,<div><br></div><div>My motivation was to allow clang to keep the semantic information for "long long" to "int" cast. I assume the C/C++ semantic does not specify the behavior in case of overflow for signed integers. Which means we can assume (trust the programmer!?) that signed overflow/underflow do not happen on the truncation. Unsigned integer is "unfortunately" probably properly defined in C/C++.</div><div><br></div><div>Note that it might be useful to have a nuw attribute at C/C++ level as well, that could be applied to unsigned integer variables by the programmer when he wants to be nice to his preferred compiler.</div><div><br></div><div>My true motivation behind that is because I end-up with trunc/sext for getelementptr arguments sometimes and I would love to get rid of the spurious ones. They are mostly caused by users casting a size_t into an int on a 64 bit architecture and using that as an array index. I am not sure I am allowed to say that the size_t to int cast is a signed cast.</div><div><br></div><div>Then in OpenCL (spir64):</div><div><br></div><div>int i = get_global_id(0); // returns a size_t</div><div>short val = i;</div><div>... = val * A[i];</div><div><br></div><div>would become:</div><div><br></div><div> %global_id.0 = i64 get_global_id(i32 0)</div><div> %i = trunc nsw i64 %global_id.0 to i32</div><div> %idx = sext i32 %i to i64</div><div> %A.addr = gep i16, i16* %A.ptr, i64 %idx</div><div> %A.val = load i16 %A.addr</div><div> %i.val = trunc nsw i32 %i to i16</div><div> %val = mul nsw i16 %i, %A.val</div><div><br></div><div>And I can get rid of the truncation for the gep (and can "upgrade" the i16 computation to i32 in LLVM if I want so).</div><div>Does that make sense?<br></div><div><br></div><div>Best regard.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 4, 2017 at 7:41 AM, Dr.-Ing. Christoph Cullmann <span dir="ltr"><<a href="mailto:cullmann@absint.com" target="_blank">cullmann@absint.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<span><br>
> 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>
</span>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>
<br>
Greetings<br>
Christoph<br>
<span><br>
><br>
> 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>
</span>> ______________________________<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>
<span class="gmail-m_1213557073324967062HOEnZb"><font color="#888888"><br>
--<br>
----------------------------- Dr.-Ing. Christoph Cullmann ---------<br>
AbsInt Angewandte Informatik GmbH Email: cullmann@AbsInt.com<br>
Science Park 1 Tel: <a href="tel:%2B49-681-38360-22" value="+496813836022" target="_blank">+49-681-38360-22</a><br>
66123 Saarbrücken Fax: <a href="tel:%2B49-681-38360-20" value="+496813836020" target="_blank">+49-681-38360-20</a><br>
GERMANY WWW: <a href="http://www.AbsInt.com" rel="noreferrer" target="_blank">http://www.AbsInt.com</a><br>
------------------------------<wbr>------------------------------<wbr>--------<br>
Geschäftsführung: Dr.-Ing. Christian Ferdinand<br>
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail-m_1213557073324967062gmail_signature"><div dir="ltr"><b>Alexandre Isoard</b><br></div></div>
</div></div>