LLVM 10.0.1-rc1 release update

Hi,

All the patches for LLVM 10.0.1-rc1 have been merged, and I'm just waiting
for the CI jobs to finish. I will tag the release tomorrow if all
goes well.

Don't worry if you have a change that didn't make it into LLVM 10.0.1-rc1,
there is still another month to merge changes before LLVM 10.0.1-rc2.

-Tom

Hi Tom,

We just upstreamed machine instruction model for Marvell's upcoming processor ThunderX3. This link is https://reviews.llvm.org/D78129/new/

Our customers asked us if we can put it on 10.0.1 release as that will meet their immediate need. They also want it onto LLVM 9.0.2 -- not sure if there is a plan for it.

Can we put it in? What should we do?

Thanks,

Wei Zhao
__o Hurry ...
_ \<,_
(_)/ (_)

Hi Tom,

We just upstreamed machine instruction model for Marvell's upcoming processor ThunderX3. This link is https://reviews.llvm.org/D78129/new/

Our customers asked us if we can put it on 10.0.1 release as that will meet their immediate need. They also want it onto LLVM 9.0.2 -- not sure if there is a plan for it.

Can we put it in? What should we do?

This is a much bigger patch than what we normally take into the release branch.
Is the machine instruction model necessary only for optimal performance?
Is it possible to generate valid code for ThunderX3 in LLVM 10.0.0 without the
machine instruction model?

-Tom

I am mostly a lurker on this list. I hope my perspective is useful.

It would make much more sense to me to call them 10.0.1-10.0.6 and the last one having an rc cycle and becomes 10.1.

background:

I am one of those people who prefers the .n release when deciding when to upgrade our product's toolchain. We have 700k+ lines of high performance, snarly, heavily templated. and sometimes bad C++ code written by many engineers of various capability over the last decade (the last part accurate for most established appliance products.) Every toolchain upgrade is an archeological effort in which we find things that don't work any more (and often never worked right) and need fixing, often with a rototiller. The last round was particularly nasty for us, taking about 20 MM to complete. The last thing I want is a toolchain that I don't have maximum confidence in.

Isn't one of the jobs of the release process to say "this is the next stable release that we think the general user community can/should upgrade to"? Given that there are no release candidates, how is someone to know that 10.3 or 10.5 is safe to upgrade to? You may make the developer process simpler, but I think this makes the end user (and possibly distro folks) process more complex and require them to understand that 10.1 is just a calendar event and not an indication that this is a safe, reliable release to move to. I would think that at least one cycle of rc where teams are all encouraged to build and test in their own way to look for serious flaws would provide some increased confidence that this is a safe choice. I appreciate the idea that improving the CI is important, but even massive investments in CI (we have teams and millions of dollars of committed to CI testing hardware) are not a replacement for wider QA and release testing.

jerry