+lldb-dev. I can't speak for everyone. but at least as far as I know, LLDB always builds the clang that it uses. I added lldb-dev in case the situation is different for anyone else.
On Sat, Mar 7, 2015 at 3:26 PM Sanjoy Das <san...@playingwithpointers.com> wrote: > Does LLDB always build the LLVM/Clang it links to? > > At this time, I don't have an idea that is better than a separate > LLVM_ENABLE_FAIL_FAST_ITERATORS #define, so I'd like to go forward > with that. The only thing I dislike about a separate #define that if > it is not enabled by default in the +Asserts build then realistically > it won't get used. However, if LLDB always links to a private copy of > LLVM/Clang then it could keep LLVM_ENABLE_FAIL_FAST_ITERATORS not > #defined in both the no-asserts and the with-asserts build (or keep it > #defined in both); and get the ABI compatibility it needs. > > Does this make sense? > > -- Sanjoy > > On Fri, Mar 6, 2015 at 1:01 PM, Sanjoy Das > <san...@playingwithpointers.com> wrote: > > I guess we could always set a bit in one of the pointers in the > > DenseMap and DenseMapIterators to indicate that that *specific* > > instance of X is epoch enabled. That won't be fun to implement > > though: we won't be able to inherit from DebugEpochBase but will have > > to conditionally embed some fields /after/ the normal set of fields. > > > > On Fri, Mar 6, 2015 at 12:57 PM, Zachary Turner <ztur...@google.com> > wrote: > >> Didn't +David Majnemer have an idea surrounding pointer unions? I'm not > >> sure if he mentioned it on this thread or whether it would work, but I > +'ed > >> him so maybe he can chime in. > >> > >> On Fri, Mar 6, 2015 at 12:56 PM Sanjoy Das <sanjoy@playingwithpointers. > com> > >> wrote: > >>> > >>> > It has more impact than that though. It also means we need 3x the > >>> > registers, > >>> > 3x the function arguments, etc etc. I think this is a pretty high > cost > >>> > to > >>> > pay. > >>> > >>> The register usage I'm not too worried about since we won't actually > >>> be using the epoch values (so the regalloc should not be putting them > >>> inside registers at all in most cases); but I see how it can affect > >>> function arguments. > >>> > >>> Btw, Chandler, I thought about your idea of using template > >>> specialization to make a epoch-enabled DenseMap a different type from > >>> an epoch-disabled DenseMap (safety from symbol mangling). If mixing > >>> defined(NDEBUG) headers and !defined(NDEBUG) libs (or vice versa) is a > >>> supported use case, we'll still run into trouble with data structures > >>> that embed DenseMaps. For instance, in debug mode, LoopInfo will > >>> embed a epoch-enabled DenseMap while in release mode it will embed a > >>> epoch-disabled DenseMap and we'll have the same ABI compatibility > >>> problem there. > >>> > >>> -- Sanjoy >
_______________________________________________ lldb-dev mailing list lldb-dev@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
