[llvm-commits] Patch to allow llvm.gcroot to work with non-pointer allocas.

[Talin]

Duncan Sands <baldrick at ...> writes:

> is this really needed?  In this situation, can't you just declare two allocas:
> your struct alloca, and a pointer alloca that contains the address of the 
struct
> alloca.  You then pass the pointer alloca as the gc root.

Let me restate my argument. I think that this patch is clearly the "right thing" 
for llvm.gcroot(), and that the use of an auxiliary pointer is an unnecessary 
hack which only serves to (a) make the frontend code generator more complicated, 
and (b) make stack frames bigger than they should be. Here's my reasoning:

Originally, when I discovered that the code in Verifier.cpp would not allow me 
to use llvm.gcroot with a non-pointer alloca, I assumed that there was a reason 
for this guard condition to be there - that if I were to look deeper into the 
mechanics of the GC lowering pass, I would find some limitation that made the 
lowering pass unable to work with non-pointer allocas.

However, I discovered no such limitation. The lowering pass works just fine (as 
far as I can tell - more on this in a minute) with non-pointer allocas. The only 
thing that doesn't work is the automatic initialization of roots to NULL, which 
I am not using anyway and which can be turned off in your GC strategy.

By "working fine" in this case, what I mean is that my GC strategy plugin 
appears to be getting valid stack offsets and metadata for both pointer and non-
pointer allocas. I won't say for certain that it's working until I actually get 
to the point where I can run a collection pass, and I'm not quite there yet.

So my argument is that the restriction to pointer allocas is both unnecessary 
and inconvenient, and therefore should be removed. That's what this patch does.

BTW, I'm curious - is anyone using the second argument to llvm.gcroot other than 
myself?