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

[Sanjoy Das]

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