[PATCH] [Core] Update references in parallel

Filipe Cabecinhas filcab at gmail.com
Thu Mar 19 21:32:11 PDT 2015

If you're going to discuss such a design change, might I suggest starting a
thread for that purpose? And link to this thread/phabricator patch, of



On Thursday, March 19, 2015, Davide Italiano <davide at freebsd.org> wrote:

> On Fri, Mar 20, 2015 at 2:33 AM, Sean Silva <chisophugis at gmail.com
> <javascript:;>> wrote:
> > I really don't like this approach. It has large memory contention in the
> inner loop even though this computation doesn't inherently have any. Also
> it is using an extremely cache-unfriendly design, along with putting a
> `new` into the inner loop, causing contention inside the memory allocator
> besides the usual allocation slowness.
> >
> > We could just store a bit inside the Atom that marks it as dead. That
> avoids a bunch of hash table lookups in the _deadAtoms map anyway. We have
> a ton of space in the Atom base class in the _definition field, which is
> only using 2 bits of a pointer-aligned field (aligned to the vptr). We
> already have the _definition field loaded (and in cache) due to the
> dyn_cast above (which checks _definition). So it's just an OR and a store
> to mark it: no extra loads, no extra cache misses, no synchronization.
> >
> >
> I like your design better, no doubt, but as previously discussed this
> needs some fundamental re-design of the code (i.e. atoms  can't be
> passed as const anymore). cc:ing all the other people involved so we
> can have a discussion about pro/cons and if this is the direction we
> want to take.
> --
> Davide
> "There are no solved problems; there are only problems that are more
> or less solved" -- Henri Poincare
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu <javascript:;>
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150319/4f82dabd/attachment.html>

More information about the llvm-commits mailing list