[lldb-dev] [llvm] r231214 - Revert "[ADT] fail-fast iterators for DenseMap"

[Zachary Turner]

+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 <sanjoy at 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
> <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>
> 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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20150308/88345584/attachment.html>