[LLVMdev] 3.4.1 Release Plans

[Tom Stellard]

On Thu, Apr 03, 2014 at 04:31:31PM +0100, Renato Golin wrote:
> 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.
> 

I thought these were new intrinsics, so there would be no external tools
that relied on specific names.

> 
> > 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.
> 

I'm suggesting doing this on the release branch only.  If I understand
correctly, this is essentially what you are suggesting below, right?

> 
> > 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.
> 

OK, I know Tim has replied to this thread, but I just want to make sure
there are no surprises.  The subject of the email doesn't make it clear
that we are discussing merging these specific patches into the stable
branch, and I want to make sure all interested parties, especially code
owners have a chance to respond.

-Tom

> 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