[LLVMdev] Function inlining creates uninitialized stack roots

Talin viridia at gmail.com
Sat Oct 2 13:58:36 PDT 2010


On Sat, Oct 2, 2010 at 12:59 PM, nicolas geoffray <
nicolas.geoffray at gmail.com> wrote:

> Hi Talin,
>
> You are not doing something wrong, it is just that the LLVM optimizers
> consider llvm.gcroot like a regular function call. The alloca is moved in
> the first block most probably because the inliner anticipates another
> optimization pass (the mem2reg).
>

OK, well, is there anything that can be done?

>
> Cheers,
> Nicolas
>
> On Sat, Oct 2, 2010 at 8:28 PM, Talin <viridia at gmail.com> wrote:
>
>> I'm still putting the final touches on my stack crawler, and I've run into
>> a problem having to do with function inlining and local stack roots.
>>
>> As you know, all local roots must be initialized before you can make any
>> call to a function which might crawl the stack. My compiler ensures that all
>> local variables of a function are allocated, declared as root, and
>> initialized in the first block.
>>
>> However, the function inlining pass does not seem to preserve these
>> constraints. For example, say I have a function F:
>>
>>    void F() {
>>      f1();
>>      f2();
>>    }
>>
>> Let's say that f1() causes a stack crawl (perhaps by triggering a
>> collection cycle), and that f2() declares a stack root 'a'. If the optimizer
>> decides to inline f2, then by the time the GCPrinter is called the resulting
>> code looks like this:
>>
>>    - a = alloca
>>    - call f1
>>    - call llvm.gcroot(a)
>>    - store null, a
>>
>> The inliner moved the alloca instruction to the top of the function, but
>> not the call to llvm.gcroot or the initialization of the variable. In other
>> words, the initialization of the root occurs *after* the call to f1. This
>> means that the stack crawler is seeing garbage and therefore crashes hard.
>> (Also, I've observed that the call to llvm.gcroot and the initialization
>> might not even be in the first block anymore.)
>>
>> As per usual, I'm not sure if this is a bug in LLVM or my doing something
>> wrong...
>>
>> --
>> -- Talin
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>


-- 
-- Talin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101002/04d52b54/attachment.html>


More information about the llvm-dev mailing list