<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p style="margin-top:0;margin-bottom:0">Cheers Tim,<span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;"></span></p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0">The real problem is not just in the printing though, any code can misinterpret the true value if one queries isNegative(). negate() will also produce the original value.</p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<p style="margin-top:0;margin-bottom:0"><span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;">I didn't know about APSInt. </span><span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;">It
seems I have been </span><span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;">mislead and I think I will have to go back
to some of my past patches... I know I'm not the only one to be caught out by this behaviour though, APSInt looks like a safer type to use.</span><br>
</p>
<p style="margin-top:0;margin-bottom:0"><span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;"><br>
</span></p>
<p style="margin-top:0;margin-bottom:0"><span style="font-family: Calibri, Helvetica, sans-serif, EmojiFont, "Apple Color Emoji", "Segoe UI Emoji", NotoColorEmoji, "Segoe UI Symbol", "Android Emoji", EmojiSymbols; font-size: 16px;">Thanks again,</span></p>
<p style="margin-top:0;margin-bottom:0"><br>
</p>
<div id="Signature">
<div id="divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); background-color:rgb(255,255,255); font-family:Calibri,Arial,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<p></p>
<p style="font-family:"Times New Roman""><span style="font-family:Calibri,Helvetica,sans-serif">Sam Parker</span></p>
<span style="font-family:Calibri,Helvetica,sans-serif"></span>
<p style="font-family:"Times New Roman""><span style="font-family:Calibri,Helvetica,sans-serif">Compilation Tools Engineer | Arm</span></p>
<span style="font-family:Calibri,Helvetica,sans-serif"></span>
<p style="font-family:"Times New Roman""><span style="font-family:Calibri,Helvetica,sans-serif">. . . . . . . . . . . . . . . . . . . . . . . . . . .</span></p>
<span style="font-family:Calibri,Helvetica,sans-serif"></span>
<p style="font-family:"Times New Roman""><span style="font-family:Calibri,Helvetica,sans-serif">Arm.com</span></p>
<p></p>
</div>
</div>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Tim Northover <t.p.northover@gmail.com><br>
<b>Sent:</b> 31 January 2019 13:25:32<br>
<b>To:</b> Sam Parker<br>
<b>Cc:</b> llvm-dev@lists.llvm.org; nd<br>
<b>Subject:</b> Re: [llvm-dev] Behaviour of APInt</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">On Thu, 31 Jan 2019 at 12:56, Sam Parker via llvm-dev<br>
<llvm-dev@lists.llvm.org> wrote:<br>
> The APInt documentation states that it 'is a functional replacement for common<br>
> case unsigned integer type', but I'm not seeing this because the internal logic<br>
> is that the value is always treated as negative if the most significant bit is<br>
> set.<br>
<br>
I take that as saying it's a 2s-complement type rather than overflow<br>
being UB, but the statement may still be misleading.<br>
<br>
> I know there are operators for when the sign matters, but from my example,<br>
> either my understanding or the functionality is broken.<br>
<br>
It's definitely quirky that it's always printed as a signed integer.<br>
My guess would be it stems from a very early decision about the<br>
friendliest ways to print IR's iN types, which was probably its first<br>
use-case (i.e. most people would prefer to see i64 -1 over i64<br>
18446744073709551616). But I haven't done the archaeology to confirm<br>
it.<br>
<br>
> If an abstract<br>
> structure exists, why does the MSB still represent the sign? Especially<br>
> when it's supposed to be an unsigned type!<br>
<br>
I think it's be more correct to say it's an arbitrary precision type<br>
that could be either sign (again, much like LLVM's iN). There's a<br>
separate APSInt for a type that genuinely is either signed or unsigned<br>
in all cases.<br>
<br>
Cheers.<br>
<br>
Tim.<br>
</div>
</span></font></div>
</body>
</html>