<div dir="ltr">+lldb-dev.  <div><br></div><div>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.<br><br><div class="gmail_quote">On Sat, Mar 7, 2015 at 3:26 PM Sanjoy Das <<a href="mailto:sanjoy@playingwithpointers.com">sanjoy@playingwithpointers.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Does LLDB always build the LLVM/Clang it links to?<br>
<br>
At this time, I don't have an idea that is better than a separate<br>
LLVM_ENABLE_FAIL_FAST_<u></u>ITERATORS #define, so I'd like to go forward<br>
with that.  The only thing I dislike about a separate #define that if<br>
it is not enabled by default in the +Asserts build then realistically<br>
it won't get used.  However, if LLDB always links to a private copy of<br>
LLVM/Clang then it could keep LLVM_ENABLE_FAIL_FAST_<u></u>ITERATORS not<br>
#defined in both the no-asserts and the with-asserts build (or keep it<br>
#defined in both); and get the ABI compatibility it needs.<br>
<br>
Does this make sense?<br>
<br>
-- Sanjoy<br>
<br>
On Fri, Mar 6, 2015 at 1:01 PM, Sanjoy Das<br>
<<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.<u></u>com</a>> wrote:<br>
> I guess we could always set a bit in one of the pointers in the<br>
> DenseMap and DenseMapIterators to indicate that that *specific*<br>
> instance of X is epoch enabled.  That won't be fun to implement<br>
> though: we won't be able to inherit from DebugEpochBase but will have<br>
> to conditionally embed some fields /after/ the normal set of fields.<br>
><br>
> On Fri, Mar 6, 2015 at 12:57 PM, Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br>
>> Didn't +David Majnemer have an idea surrounding pointer unions?  I'm not<br>
>> sure if he mentioned it on this thread or whether it would work, but I +'ed<br>
>> him so maybe he can chime in.<br>
>><br>
>> On Fri, Mar 6, 2015 at 12:56 PM Sanjoy Das <<a href="mailto:sanjoy@playingwithpointers.com" target="_blank">sanjoy@playingwithpointers.<u></u>com</a>><br>
>> wrote:<br>
>>><br>
>>> > It has more impact than that though. It also means we need 3x the<br>
>>> > registers,<br>
>>> > 3x the function arguments, etc etc. I think this is a pretty high cost<br>
>>> > to<br>
>>> > pay.<br>
>>><br>
>>> The register usage I'm not too worried about since we won't actually<br>
>>> be using the epoch values (so the regalloc should not be putting them<br>
>>> inside registers at all in most cases); but I see how it can affect<br>
>>> function arguments.<br>
>>><br>
>>> Btw, Chandler, I thought about your idea of using template<br>
>>> specialization to make a epoch-enabled DenseMap a different type from<br>
>>> an epoch-disabled DenseMap (safety from symbol mangling).  If mixing<br>
>>> defined(NDEBUG) headers and !defined(NDEBUG) libs (or vice versa) is a<br>
>>> supported use case, we'll still run into trouble with data structures<br>
>>> that embed DenseMaps.  For instance, in debug mode, LoopInfo will<br>
>>> embed a epoch-enabled DenseMap while in release mode it will embed a<br>
>>> epoch-disabled DenseMap and we'll have the same ABI compatibility<br>
>>> problem there.<br>
>>><br>
>>> -- Sanjoy<br>
</blockquote></div></div></div>