[LLVMdev] recognizing DTORs and vptr updates in LLVM.

[Kostya Serebryany]

On Mon, Mar 19, 2012 at 5:24 PM, Eli Friedman <eli.friedman at gmail.com>wrote:

> On Mon, Mar 19, 2012 at 4:52 PM, Chandler Carruth <chandlerc at google.com>
> wrote:
> > On Mon, Mar 19, 2012 at 4:46 PM, Eli Friedman <eli.friedman at gmail.com>
> > wrote:
> >>
> >> Given that, I'm not sure I really see the issue with just
> >> special-casing any store where the value stored is a pointer to a
> >> global... but it could be argued either way, I guess.
> >
> >
> > I users expect this to "just work", why not extend the language and make
> it
> > just work?
>
> I'm not sure anyone really expects this to "just work", just that they
> did it by accident.  Making cross-thread unsynchronized virtual calls
> on an object which is being destroyed strikes me as a construct nobody
> would intentionally write.
>
> > We could, as an implementation, decide to emit these as relaxed atomic
> > stores, making the code well defined without changing the semantics (or
> > optimization) in any meaningful way, right?
>
> Making all vptr loads and stores atomic would block some optimizations
>

.. and will not solve my problem -- I still need to distinguish between
"benign-for-practical-purposes" and "definitely-harmful" vptr races.
The only difference between those two cases lies outside of the
instrumented function.
(it depends on the dynamic type of the object being destroyed).

--kcc


> (specifically, we can't perform certain optimizations involving
> memcpy, and IIRC some optimizers have incomplete atomics handling).
> Not sure if it would have much practical impact, though.
>
> Specifically just making vptr stores in destructors "unordered", and
> making unordered stores which don't change the stored value
> effectively no-ops in the memory model, could work too; the potential
> impact on optimization is much less, and I don't think the model
> changes would lead to any optimizer changes.
>
> -Eli
> _______________________________________________
> 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/20120319/3ecb1b45/attachment.html>