On 3 April 2014 15:51, Tom Stellard <[email protected]> wrote: > 1. Rename the intrinsics so that they end up at the bottom of the list. > These are only accessed via clang builtins, so the names should matter, > right?
No, that would create API compatibility. We don't know if there is any external tool that uses the same generated files/enums. > 2. Don't generate the intrinsic enum at buildtime. Generate it once > offline and check it in and then modify the build system to use this > copy. This would work well on release branches, but not on trunk, as that's the whole point of TableGen. I can't think of an easy way to make it work for further point releases, though. > 3. Don't add these intrinsics. That would be the easiest, but maybe not the best solution. As I said before, this is the first stable dot release we do and I don't think it's going to be perfect. We'll probably get many things wrong and people shouldn't be afraid of experimentation to the detriment of early commitment to defective procedures. We could create an extra step of the dot release to move all new enum fields to the bottom on the generated files to keep compatibility. Further dot releases will have to kludge new patches on top of those modified branches. If that doens't work, from release 3.5 we won't change the branch 3.4 any more, so whatever we do wrong, we can easily discard and try again. > Also, before we get too far into this, I would really like to get > approval from Tim Northover (AArch64 code owner) and Evan Cheng (ARM > code owner) for merging these patches. Can you ping them and ask them > to reply on list with their response. I think we need to get our procedure settled first. The probability of the patches being accepted by the overall community but refused by the code owners is very small, especially with so many core developers copied and replying to this thread (and other past threads). So, getting the approval of the code owners would be a good thing, but not at this stage, I think. So far, the only worrying issues I have seen, as mentioned by Jiangning before, were: * int64_t mangling changes * llvm::intrinsic enum order My personal opinion is that the uint64_t should not be applied, since it changes the mangling in respect to 3.4, and the enum should be fixed (by moving the new ones to the end on the generated files). cheers, --renato _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
