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

[Sanjoy Das]

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