On Wed, Apr 13, 2011 at 3:54 PM, Jonas Paulsson <jnspaulsson at
hotmail.com> wrote:> As my target supports signed / unsigned interpretation of operands, I was a
> bit startled to find that the LLVM I/R does not express this info of the
> integer operands. I want to create an eg unsigned mul if the operands are
> unsigned, using an intrinsic.
>
> I find that with -g, metadata is generated which seems to convey this
> information. Is it safe to base this type of transformation on the
metadata?
It's not safe to change behavior based on metadata since it's supposed
to be deletable.
Also, you don't want code compiled without debug information to behave
differently from code with debug information because that would make
debugging harder (the bug might disappear when debug information is
enabled).
> If not, what are the options?
For mul, it shouldn't matter as long as the result type is the same as
the operand types (as LLVM IR enforces). So in the simple cases you
can just choose whichever is faster (or arbitrarily pick (un)signed).
If your machine has operations like e.g. i32 * i32 --> i64 (like x86
has), for which signedness *does* matter, you could use those
instructions for cases like this:
- Unsigned: if the code is i64 * i64 --> i64 and you know the top 32
bits of each operand are zero, for example because they're zexts from
i32 or smaller, or constants that fit in 32-bit unsigned integers.
- Signed: if the code is i64 * i64 --> i64 and the top 33 bits of each
operand are equal (i.e. it has at least 33 sign bits), for example
because they're sexts from i32 or smaller or constants that fit in
32-bit signed integers.
(Similarly for i16 * i16 --> i32, i64 * i64 --> i128 etc. of course)