<div dir="ltr">Didn't <a class="GWVZpf fS" id="IloFPc-2" href="mailto:majnemer@google.com" tabindex="-1">+David Majnemer</a> 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.<br></div><br><div class="gmail_quote">On Fri, Mar 6, 2015 at 12:56 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">> It has more impact than that though. It also means we need 3x the registers,<br>
> 3x the function arguments, etc etc. I think this is a pretty high cost 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>