[LLVMbugs] [Bug 16778] New: llvm.lifetime.start/end conflict with use of llvm.gcroot

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=16778

            Bug ID: 16778
           Summary: llvm.lifetime.start/end conflict with use of
                    llvm.gcroot
           Product: new-bugs
           Version: 3.2
          Hardware: PC
                OS: other
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: don.apoch at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10975
  --> http://llvm.org/bugs/attachment.cgi?id=10975&action=edit
Example IR code which causes the issue

There appears to be a fundamental conflict of interest between
llvm.lifetime.start/end intrinsics and the use of the llvm.gcroot intrinsic.
Due to the merging of stack slots, it is possible for GC roots to contain
unexpected values if the GC is triggered at certain points in the lifetime of
the stack slot(s) in question.

This is mostly exacerbated by the function inlining pass, which introduces
lifetime intrinsics to the IR.

Consider the following scenario:

 - Function A uses one stack slot which is a GC root
 - Function B uses three stack slots, two of which are GC roots and one is not
 - Function B calls function A
 - The call to A becomes inlined due to optimization passes
 - GC safepoints (and therefore collector invocations) can occur before and/or
after the call to A


In this case the optimizer introduces lifetime.start and .end calls surrounding
the stack slot used by function A. Given the right circumstances this can merge
the stack slot used by A into the non-gcroot slot used by function B. (Other
scenarios I've observed include merging the slot into a different gcroot stack
slot, which then carries the wrong metadata.)

If the GC is invoked at the right time during this sequence, it will attempt to
traverse a root which does not in fact contain a valid pointer. Again the other
possible scenario is that the pointer *is* valid but is associated with the
wrong metadata.

Since gcroot carries no lifetime semantics, it appears to be fundamentally
impossible to mix the use of gcroot with lifetime.start/end. I am currently
working around this issue by using a GCStrategy with a custom lowering pass
that simply eliminates lifetime intrinsic calls, but obviously this incurs some
expense in terms of stack space.

I'm attaching a case that reproduces this behavior; the various calls can
largely be ignored except for the calls that trigger garbage collection passes.
I apologize in advance for the large sample case, but it's proven extremely
difficult to get this to reliably repro in simpler scenarios.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20130802/6120c05b/attachment.html>