llvm dev - Sep 2010 - [LLVMdev] Recommended order between llvm.gcroot and llvm.dbg.declare?

So I understand now that calls to llvm.gcroot have to be in the first block.
(Might be a good idea to mention this in the GC docs).

For each local variable that is created, there are 5 possible steps.

   1. Allocate the storage for the variable using alloca().
   2. Declare the variable as a root via llvm.gcroot.
   3. Initialize the variable to zero.
   4. Declare the DWARF debugging info for the variable via
   llvm.dbg.declare.
   5. Evaluate the initializer expression for the variable and store it to
   the variable.

(It might seem that step 3 is redundant, but what if step 5 triggers a
garbage collection cycle? We need to insure that the alloca doesn't contain
stack junk if this happens, so we need to zero-initialize all roots before
any initializers are run. I'm hoping that the optimizer will eliminate the
redundant store if the initializer expression turns out to be trivial.)

My question is this: Is there any constraint on the order of steps 2, 3 and
4? And does step 4 also have to go in the first block?

Another related question: What effect does llvm.gcroot have on
optimizations? For example, I assume a variable that has been declared as a
root can't be converted to a register variable. Are there any other impacts
I should know about?

-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100926/9dda6b5f/attachment.html>

On Sep 26, 2010, at 3:01 PM, Talin wrote:
> So I understand now that calls to llvm.gcroot have to be in the first
block. (Might be a good idea to mention this in the GC docs).
> 
> For each local variable that is created, there are 5 possible steps.
> Allocate the storage for the variable using alloca().
> Declare the variable as a root via llvm.gcroot.
> Initialize the variable to zero.
> Declare the DWARF debugging info for the variable via llvm.dbg.declare.
> Evaluate the initializer expression for the variable and store it to the
variable.
> (It might seem that step 3 is redundant, but what if step 5 triggers a
garbage collection cycle? We need to insure that the alloca doesn't contain
stack junk if this happens, so we need to zero-initialize all roots before any
initializers are run. I'm hoping that the optimizer will eliminate the
redundant store if the initializer expression turns out to be trivial.)
> 
> My question is this: Is there any constraint on the order of steps 2, 3 and
4? And does step 4 also have to go in the first block?
Only requirement for llvm.dbg.declare is that it must be after 1. Debug info
handling is completely oblivious of llvm.gcroot so no idea about your other
questions.

-
Devang
> 
> Another related question: What effect does llvm.gcroot have on
optimizations? For example, I assume a variable that has been declared as a root
can't be converted to a register variable. Are there any other impacts I
should know about?
> 
> -- 
> -- Talin
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100927/dba30835/attachment.html>