LLVM 2.0 and integer signedness

Hello, Alberto.

I'm using llvm for instrumenting code, and I need to know if there's a way to
difference between signed and unsigned Values of integer type during an
optimization pass.

Types are signless in LLVM 2, operations are not. So, you should
probably inspect insts itself, not their operands.

The problem is that what i'm instrumenting is loads and stores, plus function call arguments and return values, which have no signedness information.

The problem is that what i'm instrumenting is loads and stores, plus
function call arguments and return values, which have no signedness
information.

Why do you need this?

-Chris

I'm using LLVM to instrument C code to test the efectiveness of some methods of error detection with dynamic invariants (see http://citeseer.ist.psu.edu/hangal02tracking.html). I'm using also a range invariant (max an min values seen). The problem is that for those invariants, I need to know if the value is signed or not (0xFF can be -1 or 255, depending on signed/unsigned).

Alberto

I'm using LLVM to instrument C code to test the efectiveness of some
methods of error detection with dynamic invariants (see http://
citeseer.ist.psu.edu/hangal02tracking.html). I'm using also a range
invariant (max an min values seen). The problem is that for those
invariants, I need to know if the value is signed or not (0xFF can be
-1 or 255, depending on signed/unsigned).

Why not track the value range as both signed and unsigned? You have to be able to do this in any case, in order to handle "int -> uint" casts (for example). At any particular point in the code, you can use the signed or unsigned range invariant based on whatever you need.

-Chris

I'm using LLVM to instrument C code to test the efectiveness of some
methods of error detection with dynamic invariants (see http://
citeseer.ist.psu.edu/hangal02tracking.html). I'm using also a range
invariant (max an min values seen). The problem is that for those
invariants, I need to know if the value is signed or not (0xFF can be
-1 or 255, depending on signed/unsigned).

Why not track the value range as both signed and unsigned? You have to be able to do this in any case, in order to handle "int -> uint" casts (for example). At any particular point in the code, you can use the signed or unsigned range invariant based on whatever you need.

I'm tracking reads and writes to variables in fixed source code points, and variables cannot change their types. For example:

int a;
uint b;

a = -2;
b = (uint) a;

For a=-2 i´ll have a signed-write-invariant to a. Then for b = a, i'll have a signed-read-invariant from a, and an unsigned-write-invariant to b. When I see a write to a variable, i want to be able to know if that variable has sign or not. For this stage of the research it's not very important because the test set we are using only uses signed integers, but later on we will have to use both signed and unsigned and then it will be problematic.

Leaving signed and unsigned problems aside, how can i read debugging symbols from inside an opt modulepass?

Alberto

I'm tracking reads and writes to variables in fixed source code
points, and variables cannot change their types. For example:

int a;
uint b;

a = -2;
b = (uint) a;

Okay, that's somewhat problematic in the face of pointers (where you can cast int* to uint*, etc), but...

Leaving signed and unsigned problems aside, how can i read debugging
symbols from inside an opt modulepass?

Debug info is represented as llvm global variables. You can see these with 'llvm-gcc -g -S -o - -emit-llvm t.c'. They can be walked like any other global, but we don't currently have a good api to make this easy for debug info specifically.

-Chris