[llvm-dev] [frontend-dev][beginner] Allocation of structures

[Dimitri Racordon via llvm-dev]

Thanks for this comprehensive answer!
I’m slowly but surely to understand better about all this.

That may sound scary,

Yes it does! That said, I’m not sure need to care that much about the C++ ABI, as I don’t plan on linking my IR with C++ directly. It is very interesting to see how it works though, as I’ll probably need to solve the same kind of problems for my own frontend language.

The result of an alloca is a pointer to the stack frame of the current function, so returning it doesn't make sense (like returning the address of a local variable in C). Again, this problem isn't really related to LLVM per se and the easiest way to think about it is in terms of how to lower to C.
Decisions about object destruction are up to the frontend. At the C or LLVM level they just turn into function calls or whatever you use to implement the semantics that the frontend requires. In other words, if you want an object to be destroyed, it's up to your frontend to emit code to perform the destruction wherever the destruction is expected to occur.

I understand my second question was probably very unclear. When I said “destroyed”, I wasn’t talking about calls to C++ (or any other frontend language) destructors, but more about what is happening to the memory that was stack allocated. Let’s consider the following IR:

define i32 @f() {
entry:
  %0 = alloca i32
  store i32 123, i32* %0
  %1 = load i32, i32* %0
  ret i32 %1
}

define i32 @main() {
entry:
  %0 = alloca i32
  %1 = call i32 @f()
  store i32 %1, i32* %0
  %2 = load i32, i32* %0
  ret i32 %2
}

As I understand it, f will allocate a new 32 bit memory space on its stack frame, and stores the value 123 in it. But what I’m not sure about is what’s happening to that alloca when f returns. If the alloca is in the frame of f, then the value stored at that location should be deallocated (which is what I meant by "destroyed") when f returns, and so I don’t understand what makes the `store i32 %1, i32* %0` successfully storing 123 in the alloca of the main function. If I had to make a guess, I would say the value pointed by %0 in f is copied to the alloca pointed by %0 in main (which is what I meant by “copy from the runtime of the callee to that of the caller”). With primitive types such as i32, this probably doesn't matter, since they would fit in a CPU register, but what if %0 was an alloca for a very large struct? I guess that’s what RVO is all about optimising, but I’d like to confirm that assumption.

Once again, I apologise for my poor knowledge of these kind of low-level semantics.

Best,

Dimitri Racordon
CUI, Université de Genève
7, route de Drize, CH-1227 Carouge - Switzerland
Phone: +41 22 379 01 24

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170601/87e32850/attachment.html>