On Thu, Apr 3, 2014 at 1:42 AM, Renato Golin <[email protected]>wrote:
> On 3 April 2014 08:51, Richard Smith <[email protected]> wrote: > >> It looks like this could be raised to 100% by restoring the prior order >> of the llvm::Intrinsic enum? >> > > Do we want to go that far? > > I'm not against it, I've done this before, but I'm just making sure we > know what we're getting into. > 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. 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. > > 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. > 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).
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
