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 (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
Kostya Serebryany
2012-Mar-20 00:36 UTC
[LLVMdev] recognizing DTORs and vptr updates in LLVM.
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>
Chandler Carruth
2012-Mar-20 00:38 UTC
[LLVMdev] recognizing DTORs and vptr updates in LLVM.
On Mon, Mar 19, 2012 at 5:36 PM, Kostya Serebryany <kcc at google.com> wrote:> .. 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).I see. So essentially, this is purely a QoI issue, and it just happens to be so common that we can't get everyone to fix their code. Instruction-level metadata sounds better and better. =[ It's not great, but at least you have evidence that this won't be an unending series of QoI issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120319/b6d42586/attachment.html>
Maybe Matching Threads
- [LLVMdev] recognizing DTORs and vptr updates in LLVM.
- [LLVMdev] recognizing DTORs and vptr updates in LLVM.
- [LLVMdev] recognizing DTORs and vptr updates in LLVM.
- [LLVMdev] recognizing DTORs and vptr updates in LLVM.
- [LLVMdev] recognizing DTORs and vptr updates in LLVM.