[LLVMdev] recognizing DTORs and vptr updates in LLVM.

[Kostya Serebryany]

On Mon, Mar 19, 2012 at 4:30 PM, Chris Lattner <clattner at apple.com> wrote:

>
> On Mar 19, 2012, at 2:52 PM, Kostya Serebryany wrote:
>
> Hello,
>
> While instrumenting LLVM IR in ThreadSanitizer (race detector), I need
> to distinguish between a store to vtable pointer (vptr) and any other
> regular store.
> This special treatment should be limited to class DTORs, so I should also
> know when a function is a DTOR.
> Rationale: need to distinguish benign and harmful races on vptr (
> http://code.google.com/p/data-race-test/wiki/PopularDataRaces#Data_race_on_vptr
> ).
>
> Currently, I can figure out when a function is a DTOR and when a store
> touches vptr by analyzing mangled names.
> _ZN1BD1Ev=="B::~B()"
> _ZTV1B=="vtable for B"
>
> define linkonce_odr void @_ZN1BD1Ev(%struct.B* %this) unnamed_addr
> nounwind uwtable align 2 {
> entry:
>   ....
>   store i32 (...)** bitcast (i8** getelementptr inbounds ([5 x i8*]*
> @_ZTV1B, i64 0, i64 2) to i32 (...)**), i32 (...)*** %0, align 8
>
> However, this does not sound right.
> What would be the right way to pass this information from clang to LLVM?
> Will using metadata for this purpose be a right solution?
> (insn-level metadata for vptr store and module-level metadata for DTORs)
>
>
> Using instruction level metadata for this would be appropriate.  However,
> I also don't understand why a race on this is truly benign.  I'm also
> concerned that you're adding even more knobs to clang and IR for special
> case situations.
>

As for "more knobs", Chandler mentioned to me recently that being able to
identify vptr accesses will help
virtual function call inlining, so we may still need this knob for other
purposes.

--kcc


>  How many more special cases like this are you going to require?
>
> -Chris
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120319/e3049778/attachment.html>