<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Apr 3, 2014 at 1:42 AM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class=""><div class="gmail_extra"><div class="gmail_quote">
On 3 April 2014 08:51, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">It looks like this could be raised to 100% by restoring the prior order of the llvm::Intrinsic enum?</div>

</blockquote><div></div></div><br></div></div><div class="gmail_extra">Do we want to go that far?</div><div class="gmail_extra"><br></div><div class="gmail_extra">I'm not against it, I've done this before, but I'm just making sure we know what we're getting into.</div>
</div></blockquote><div><br></div><div><div>Virtually all the intrinsics have been renumbered. Suppose some dynamically-linked LLVM frontend tries to create a call to an 'fabs' intrinsic. If the libLLVM DSO is upgraded from 3.4.0 to 3.4.1, they'll start creating a 'floor' intrinsic instead. If we want to support people using the C++ ABI and upgrading an LLVM DSO, I really don't think we can change these enumerators.</div>
</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
If we keep the order in trunk, we'll have created a rule of which enum orders can't be changed (which messes up the code), if we change the stable branch only, we'll make it harder to backport and create further dot releases.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">By all means, now is the time to experiment (on stable branches), so if you want the latter, I won't oppose, but the former will face public opposition right and left, I predict.</div>
</div></blockquote><div><br></div><div>I think the latter option is the right choice. The pain of preserving the ABI belongs with our hard-working branch maintainers (and they always have the option of rejecting a change because it would break the ABI).</div>
</div></div></div>