llvm dev - Feb 2017 - Unsigned int displaying as negative

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.

I'm not sure how we'll handle this yet, very worst case scenario is to
propagate the info from clang but that's not ideal, obviously.

Thanks for all the replies!



On Wed, Feb 15, 2017 at 5:16 PM, Tim Northover <t.p.northover at
gmail.com>
wrote:
> On 15 February 2017 at 10:19, Ryan Taylor via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > We have some code to determine if the operation is a signed or
unsigned
> > operation in tablegen. Can anyone suggest a good way to get around
this?
>
> I still think this is the basic problem. Unless you're on a really
> weird architecture it really doesn't matter whether an
> originally-written operation was signed or unsigned (with the
> already-represented exception of sdiv/udiv). It's probably best to
> take a step back and reassess this rather than ploughing on trying to
> preserve long-departed information.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170215/27ef6e43/attachment.html>

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.

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>