Distinguish between signed and unsigned integers

[aaronyoo]

Want to be able to distinguish between unsigned and signed integers when translating an LLVM type to spec. This is nontrivial because LLVM doesn't support the notion of signedness in their integer type.

[pgoodman]

Some thoughts:

• ZExt and SExt return value attributes. We should probably also find a way to put these attributes into FunctionDecls as well.
• Investigate downstream uses of the value. Is it used in an arithmetic (signed) or logical shift (unsinged), in an unsigned or signed divide, in an add or sub with certain overflow characteristics, etc.

[pgoodman]

A function annotated to return a zext integer should produce a return value type of an unsigned integer, and a function annotated to return a sext integer should produce a return value type of a signed integer.

When parsing a function type or a function return value, if the integer type is un/signed, then we should add the corresponding zext or sext attributes.

[artemdinaburg]

Can someone explain why we need this? I thought the only thing that matters in LLVM-land is the comparisons, which are signed or unsigned, while all integers are always unsigned?

[aaronyoo]

So I think when I first opened this issue I was trying to translate LLVM bitcode into a "spec". If I recall correctly this spec is basically a mapping of the llvm function signature to architecture specific set of memory locations and/or registers. When generating this spec it is useful to know whether or not an LLVM integer is signed or unsigned so we can keep that information in the spec.

The problem I was trying to tackle in this issue is to figure out from LLVM bitcode if an integer variable is signed or unsigned.

As @pgoodman suggested above, one simple way to do it is to inspect instructions involving that variable and see if we can deduce the signedness of it. Here is a very simple example where that approach would work: https://godbolt.org/z/j4YbjaTPq.