Hi everyone,
I noticed that MallocInst and FreeInst have been removed from the LLVM IR as
well as the language reference[1]. May I propose that at least some
placeholder is left in that document telling the reader that these
instructions have been removed. This should be kept in at least until there is
one official release that does not support these instructions anymore.
The same goes for the addition of the indirect branch instruction. A note in
the language reference would be nice telling the reader when this instruction
has been added to the language.
Regards,
Florian
[1] http://llvm.org/docs/LangRef.html
Hi Florian,
The documentation for LLVM is intended to describe the state of the system without a historical view. To get the historical view we put major changes in the release notes. These haven't been written yet for 2.7 though.
-Chris
Ouch! Didn't see that. So at the risk of irritating those still in the process of baking 2.7, what is the sanction way of doing heap allocation going forward? 
Garrison
<please email llvmdev, not me directly>
Hi Chris,
I do understand that you don't want to keep the whole history, but to me
personally a simple line for recent changes like "introduced in 2.7" or
"removed in 2.7" would have been nice, so this might be the case for other
people, too.
We archive all the released LLVM documentations, so you can diff vs 2.6 here:
http://llvm.org/releases/2.6/docs/LangRef.html
-Chris
Ouch! Didn't see that. So at the risk of irritating those still in the process of baking 2.7, what is the sanction way of doing heap allocation going forward?
No, we only support stack allocation in LLVM IR now.
You can call out to normal malloc and free, just like any external function.
-Chris
So I gather this means that malloc was removed from the IR because there are platforms that don't have non-stack allocation semantics?
Garrison
So I gather this means that malloc was removed from the IR because there are platforms that don't have non-stack allocation semantics?
No, it was removed because it wasn't necessary, and the malloc 'instruction' didn't support 64-bit targets.
-Chris
Ah, thanks. The motivational reasons help my understanding.
Garrison
BTW, what is the state of having to index into structs using i32 and not i64
even on a 64-bit platform? Is that due to be changed as well or is there some
reason for requiring an i32?
This is further reasoning to support an iptr/intp/etc... type.
The index into a struct is a field index, not a byte offset. Are you looking to support more than 4 billion fields in a struct?
-Chris
Not yet.
I'd just like to have GEPs indices be homogeneous on all platforms to simplify
things, i.e. use homogeneous containers of indices in statically-typed
languages.