Dmitry Antipov writes: > > with write barrier inside ? The short answers are: > 1) If 'struct obj' has 100 trapped members, having 100 set_XXX functions > or macros just to set the fields is ugly; > 2) Migration from explicit memory management to garbage collection - if you > have 1M lines of code which uses 'XXX->next = ...', it's quite hard > to rewrite all stuff even with the help of modern refactoring tools. > > I realize that the whole thing is very specific and probably will never used > by the most of compiler users. But, anyway, is it technically possible to > implement such thing ? How much overhead it may introduce ?
It wouldn't be very hard to do something like this in the gimplify stage immediately after the langauge front-end has done its job: for every write through a magic pointer, call the barrier. But I'd have to question your motives for doing this. Standard C++ can already do this stuff with smart pointers and no compiler hacking at all. It's a much better tool for the job. Andrew.
