llvm dev - Feb 2017 - Unsigned int displaying as negative

Tim,

  The issue is saturation is treated differently for signed than it is for
unsigned.

Ryan

On Thu, Feb 16, 2017 at 9:49 AM, Tim Northover <t.p.northover at
gmail.com>
wrote:
> On 15 February 2017 at 17:02, Ryan Taylor <ryta1203 at gmail.com>
wrote:
> > Tim, yes, I am on a very unique architecture, just about every
> instruction
> > has a signed and unsigned operation (ie, adds, addu, subs, subu,
etc...)
> and
> > we handle signed and unsigned somewhat differently.
>
> What's special about them? Flag setting? Trapping? Not a 2s-complement
> representation? Something else entirely?
>
> Roughly, to provide decent advice I think we need to know what goes
> wrong if you map everything to unsigned operations. Both C and LLVM IR
> view that as an acceptable choice so fixing the issue is likely to be
> intricate.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170216/48d78e6e/attachment.html>

On 16 February 2017 at 10:15, Ryan Taylor <ryta1203 at gmail.com>
wrote:
> The issue is saturation is treated differently for signed than it is for
> unsigned.
Saturation is overflow, which means it's not allowed in C for unsigned
integer types (they have to wrap) and irrelevant for signed (as soon
as you overflow you're in undefined behaviour territory). LLVM IR
follows C and doesn't represent saturation -- in particular
optimization passes before CodeGen will be very happy to change your
results if you're relying on it, with or without "nsw".

ARM has some saturating instructions too. The only way to access them
is via intrinsics, both at the C level and LLVM IR.

Tim.

Yes, I saw that ARM has them as intrinsics. Hexagon has them also ( most
embedded archs are going to support saturate is my understanding) but I'm
not sure yet how they are doing it, it doesn't look like intrinsics though.

Ryan

On Thu, Feb 16, 2017 at 2:23 PM, Tim Northover <t.p.northover at
gmail.com>
wrote:
> On 16 February 2017 at 10:15, Ryan Taylor <ryta1203 at gmail.com>
wrote:
> > The issue is saturation is treated differently for signed than it is
for
> > unsigned.
>
> Saturation is overflow, which means it's not allowed in C for unsigned
> integer types (they have to wrap) and irrelevant for signed (as soon
> as you overflow you're in undefined behaviour territory). LLVM IR
> follows C and doesn't represent saturation -- in particular
> optimization passes before CodeGen will be very happy to change your
> results if you're relying on it, with or without "nsw".
>
> ARM has some saturating instructions too. The only way to access them
> is via intrinsics, both at the C level and LLVM IR.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170216/1e8f6900/attachment.html>

On 16/02/17 20:23, Tim Northover via llvm-dev wrote:
> Saturation is overflow, which means it's not allowed in C for unsigned
> integer types (they have to wrap) and irrelevant for signed (as soon
> as you overflow you're in undefined behaviour territory). LLVM IR
> follows C and doesn't represent saturation -- in particular
> optimization passes before CodeGen will be very happy to change your
> results if you're relying on it, with or without "nsw".
Surely "signed overflow" does not result in undefined behaviour in
LLVM
IR unless nsw is specified? Otherwise, the wording at 
http://llvm.org/docs/LangRef.html should be changed, because right now 
it strongly suggests to me that signed overflow will not cause any 
problems unless nsw is specified.


Jonas