I'm new to LLVM, does LLVM IR has scope for duplicated variable name ?
For example:
#x = global i32 0
define void #hello() {
%x = alloca i32, align 4
}
Does #x variable name duplicates with %x ?
Had you try to write a code that do something with these variables, you'd find that the answer is NO.
To access #x you'll have to use Module::GetGlobalVariable method, which obviously wouldn't pick up %x. Similarly, to access %x, you'd have to iterate a Functions BasicBlocks, looking for an Instruction named "x". Yes, the %x thing is not a variable, but an instruction.
Finally, at the textual IR level these values also can't be mixed in any way, because global values in LLVM are prefixed with # while local ones - with %.
Related
I'm in a process of making a native compiled language using LLVM as backend.
For a couple of special features I need to be able to do two things via LLVM API:
Provide custom relocations into both data and code segments to LLVM
Ability to insert a constant value (specifically arrays, but it doesn't really matter) into code segment, in specific places in between functions and create a relocation of it for LLVM-defined objects (assume functions, but it doesn't matter).
It looks like if I insert non-zero initialized global variables, they are going in the segment in the order of their declaration in LLVM IR module, I would like to to the same in the code segment, but it is read-only at the runtime, so let it be constants as in rdata segment.
For example:
#myConst1 = const [2 x i32 (i32)*] {MyProc1, MyProc2} // how do I put this into code segment before first instruction of MyProc1?
define i32 #MyProc1() !dbg !524 {
ret i32 5
}
#myConst2 = const [16 x i8] zeroinitializer // ideally would like to do this, and create relocations manually into this array for two pointers to both MyProc1 and MyProc2
define i32 #MyProc2(i32 %0) !dbg !524 {
ret i32 %0
}
Is this even possible to do with LLVM and it's API?
If yes, I need help to understand how, as after reading a ton of documentation I'm unable to figure out how.
Thank you.
I'm a beginner with LLVM, and I have a simple problem, but I can't find the solution in the documentation.
I'm doing a function pass that computes on instructions, and for this I need all 'data' from the instruction, I mean the operator, all operands, and the result.
My problem is, I can't get the result variable. For example, for the instruction:
%add1 = add nsw i32 %x, %y
I can have x and y name and variable, I can have the opCode, I can have add1 name, but, I can not have add1 variable.
I read all functions from the Instruction page of the documentation, and I can't find anything who looks like what I'm looking for.
So what is the proper API that can solve my problem?
Instruction inherits from Value and thus has method getName() which solves your problem.
But remember that instruction can be unnamed (such as %0) and getName probably won't return anything useful in that case
Can someone please explain me what is wrong with this code?
I think this should fetch the second argument from global array, but in fact it silently crushes somewhere inside JIT compilation routine.
My suppositions:
GEP instruction calculates memory address of the element by applying offset and returns pointer.
load instruction loads value referenced by given pointer (it dereferences a pointer, in other words).
ret instruction exits function and passes given value to caller.
Seems like I've missed something basic, but time point from which i should give up looking for answer myself is gone and i have to seek for help.
#arr = common global [256 x i64], align 8
define i64 #iterArray() {
entry:
%0 = load i64* getelementptr inbounds ([256 x i64]* #arr, i32 1, i32 0)
ret i64 %0
}
You requested the 257th item in a 256-item array, and that's a problem.
The first index given to a gep instruction means how many steps are made through the value operand - and here the value operand is not an array but a pointer to an array. That means every step there skips the entire size of the array forward - and that's why the gep actually asks for the 257th item. Using 0 as the first gep index will probably fix the problem. Then using 1 as the 2nd index will get you the 2nd item in the array, which is what you wanted. Read more about it here: http://llvm.org/docs/GetElementPtr.html#what-is-the-first-index-of-the-gep-instruction
Alternatively, it's more appropriate here to use the extractvalue instruction, which is similar to gep with implicitly uses a 0 for the first index (and there are a couple of other differences).
Regarding why the compiler crashes, I'm not sure - I'm guessing that while normally such a memory access would compile fine (and at runtime either generate a segfault or just return a bad value), here you specifically requested the gep to be inbounds, which means that a bounds check is done - and it will fail here - so a poison value is returned, which means your function is now effectively load undef. I'm not sure what LLVM does with load undef - it should probably be optimized out and the function be made to just return undef - but maybe it did something different which led to a rejection of your code.
I'm working with LLVM to take a store instruction and replace it with another so that I can take something like
store i64 %0, i64* %a
and replace it with
store i64 <value>, i64* %a
I've used
llvm::Value *str = i->getOperand(1);
to get the address that my old instruction is using, and then I create a new store via (i is the current instruction location, so this store will be created before the store I'm replacing)
StoreInstr *store = new StoreInst(value, str, i);
I then delete the store I've replaced with
i->eraseFromParent();
But I'm getting the error:
While deleting: i64%
Use still stuck around after Def is destroyed: store i64 , i64* %a
and a failure message that Assertion "use empty" && uses remain when a value is destroyed fail.
How could I get around this? I'd love to create a store instruction and then use LLVM's ReplaceInstWithInst, but I can't find a way to create a store instruction without giving it a location to insert itself. I'm also not 100% that will solve my issue.
I'll add that prior to my store replacement, I'm matching an instruction i, then getting the value I need before performing i->eraseFromParent, so I'm not sure if that is part of my problem; I'm assuming that eraseFromParent moves i along to the following store instruction.
eraseFromParent removes an instruction from the enclosing basic block (and consequently, from the enclosing function). It doesn't move it anywhere. Erasing an instruction this way without taking care of its uses first will leave your IR malformed, which is why you're getting the error - it's as if you deleted line 1 from the following C snippet:
1 int x = 3;
2 int y = x + 1;
Obviously you'll get an error on the remaining line, the definition of x is now missing!
ReplaceInstWithInst is probably the best way to replace one instruction with another. You don't need to supply the new instruction with a location to insert it with: just leave the instruction as NULL (or better yet, omit the argument) and it will create a dangling instruction which you can then place wherever you want.
Because of the above, by the way, the key method that ReplaceInstWithInst invokes is Value::replaceAllUsesWith, this ensures that you won't be left with missing values in your IR.
I'm holding a Type* in my hand. How do I find out its size (the size objects of this type will occupy in memory) in bits / bytes? I see all kinds of methods allowing me to get "primitive" or "scalar" size, but that won't help me with aggregate types...
If you only need the size because you are inserting it into the IR (e.g., so you can send it to a call to malloc()), you can use the getelementptr instruction to do the dirty work (with a little casting), as described here (with updating for modern LLVM):
Though LLVM does not contain a special purpose sizeof/offsetof instruction, the
getelementptr instruction can be used to evaluate these values. The basic idea
is to use getelementptr from the null pointer to compute the value as desired.
Because getelementptr produces the value as a pointer, the result is casted to
an integer before use.
For example, to get the size of some type, %T, we would use something like
this:
%Size = getelementptr %T* null, i32 1
%SizeI = ptrtoint %T* %Size to i32
This code is effectively pretending that there is an array of T elements,
starting at the null pointer. This gets a pointer to the 2nd T element
(element #1) in the array and treats it as an integer. This computes the
size of one T element.
The good thing about doing this is that it is useful in exactly the cases where you do not care what the value is; where you just need to pass the correct value from the IR to something. That's by far the most common case for my need for sizeof()-alike operations in the IR generation.
The page also goes on to describe how to do an offsetof() equivalent:
To get the offset of some field in a structure, a similar trick is used. For
example, to get the address of the 2nd element (element #1) of { i8, i32* }
(which depends on the target alignment requirement for pointers), something
like this should be used:
%Offset = getelementptr {i8,i32*}* null, i32 0, i32 1
%OffsetI = ptrtoint i32** %Offset to i32
This works the same way as the sizeof trick: we pretend there is an instance of
the type at the null pointer and get the address of the field we are interested
in. This address is the offset of the field.
Note that in both of these cases, the expression will be evaluated to a
constant at code generation time, so there is no runtime overhead to using this
technique.
The IR optimizer also converts the values to constants.
The size depends on the target (for several reasons, alignment being one of them).
In LLVM versions 3.2 and above, you need to use DataLayout, in particular its getTypeAllocSize method. This returns the size in bytes, there's also a bit version named getTypeAllocSizeInBits. A DataLayout instance can be obtained by creating it from the current module: DataLayout* TD = new DataLayout(M).
With LLVM up to version 3.1 (including), use TargetData instead of DataLayout. It exposes the same getTypeAllocSize methods, though.