[LLVMdev] 3.4.1 Release Plans

Renato Golin renato.golin at linaro.org
Thu Apr 3 08:31:31 PDT 2014


On 3 April 2014 15:51, Tom Stellard <tom at stellard.net> 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



More information about the llvm-commits mailing list