[llvm] r231214 - Revert "[ADT] fail-fast iterators for DenseMap"
zturner at google.com
Sat Mar 7 17:23:58 PST 2015
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 <sanjoy at playingwithpointers.com>
> 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
> <sanjoy at 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 <zturner at google.com>
> >> 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
> >> him so maybe he can chime in.
> >> On Fri, Mar 6, 2015 at 12:56 PM Sanjoy Das <sanjoy at playingwithpointers.
> >> 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
> >>> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits