[LLVMdev] RFC: Bug fix releases for 3.3 and beyond

[Dimitry Andric]

On Apr 3, 2013, at 19:51, David Chisnall <David.Chisnall at cl.cam.ac.uk> wrote:
> On 3 Apr 2013, at 18:42, Sean Silva <silvas at purdue.edu> wrote:
>> I'm not sure how difficult it actually is to follow ToT compared to one huge pain when upgrading for our full releases. I think it would be valuable to obtain feedback from projects that rely on LLVM as to how they go about integrating LLVM into their project and how our releases (and potentially dot-releases) would integrate into their development process.
> In FreeBSD, we ship the release with our release builds and periodically pull in head snapshots from time to time into head.  We occasionally cherry-pick fixes if they address problems that have been encountered by us, and we have some out-of-tree changes (although we're trying to minimise that).

Just as a reference, here is a list of trunk changes we currently have applied in FreeBSD, on top of the 3.2 release, which was imported 2012-12-23.  After 3.3 is released, we will probably pick up similar fixes, or submit them as candidates for a 3.3-stable branch.

------------------------------------------------------------------------
r248548 | andrew | 2013-03-20 09:34:30 +0100 (Wed, 20 Mar 2013) | 7 lines

Pull in r177252 from upstream clang trunk:

 Make sure to use same EABI version for external assembler as for
 integrated as.

This allows us to use gcc on a world built with clang on ARM.

------------------------------------------------------------------------
r247205 | dim | 2013-02-23 23:48:12 +0100 (Sat, 23 Feb 2013) | 12 lines

Pull in r175962 from upstream llvm trunk:

  X86: Disable cmov-memory patterns on subtargets without cmov.

  Fixes PR15115.

For the i386 arch, this should enable cmov instructions only on
-march=pentiumpro and higher.  Since our default CPU is i486, cmov
instructions will now be disabled by default.

MFC after:	1 week

------------------------------------------------------------------------
r247166 | dim | 2013-02-22 23:40:10 +0100 (Fri, 22 Feb 2013) | 27 lines

Pull in r172354 from upstream clang trunk:

  Refactor the x86 CPU name logic in the driver and pass -march and -mcpu
  flag information down from the Clang driver into the Gold linker plugin
  for LTO. This allows specifying -march on the linker commandline and
  should hopefully have it pass all the way through to the LTO optimizer.

  Fixes PR14697.

Pull in r175919 from upstream clang trunk:

  Driver: Pass down the -march setting down to -cc1as on x86 too.

  The assembler historically didn't make use of any target features, but this has
  changed when support for old CPUs that don't support long nops was added.

This should fix the long nops that still occurred in crt*.o, and
possibly other object files, if the system was compiled for a CPU that
does not support those, such as Geode.

Note that gcc on i386 also does not pass through any -march, -mcpu or
-mtune setting to gas, but this has not caused any trouble yet, because
gas defaults to i386.

Reported by:	lev
MFC after:	1 week

------------------------------------------------------------------------
r247003 | dim | 2013-02-19 18:53:32 +0100 (Tue, 19 Feb 2013) | 10 lines

Pull in r175360 from upstream llvm trunk:

  MCParser: Reject .balign with non-pow2 alignments.

  GNU as rejects them and there are configure scripts in the wild that
  check if the assembler rejects ".align 3" to determine whether the
  alignment is in bytes or powers of two.

MFC after:	3 days

------------------------------------------------------------------------
r246858 | dim | 2013-02-16 00:12:58 +0100 (Sat, 16 Feb 2013) | 13 lines

Pull in r175057 from upstream llvm trunk:

  X86: Disable generation of rep;movsl when %esi is used as a base pointer.

  This happens when there is both stack realignment and a dynamic alloca in the
  function. If we overwrite %esi (rep;movsl uses fixed registers) we'll lose the
  base pointer and the next register spill will write into oblivion.

  Fixes PR15249 and unbreaks firefox on i386/freebsd. Mozilla uses dynamic allocas
  and freebsd a 4 byte stack alignment.

MFC after:	1 week

------------------------------------------------------------------------
r246259 | dim | 2013-02-02 23:28:29 +0100 (Sat, 02 Feb 2013) | 16 lines

Pull in r170135 from upstream clang trunk:

  Dont use/link ARCMT, StaticAnalyzer and Rewriter to clang when the user
  specifies not to. Dont build ASTMatchers with Rewriter disabled and
  StaticAnalyzer when it's disabled.

  Without all those three, the clang binary shrinks (x86_64) from ~36MB
  to ~32MB (unstripped).

To disable these clang components, and get a smaller clang binary built
and installed, set WITHOUT_CLANG_FULL in src.conf(5).  During the
initial stages of buildworld, those extra components are already
disabled automatically, to save some build time.

MFC after:	1 week

------------------------------------------------------------------------
r244640 | andrew | 2012-12-23 22:41:39 +0100 (Sun, 23 Dec 2012) | 4 lines

Pull in r170096 from upstream clang trunk:

  Initial support for FreeBSD on ARM.

------------------------------------------------------------------------
r244628 | dim | 2012-12-23 14:04:00 +0100 (Sun, 23 Dec 2012) | 10 lines

Upgrade our copy of llvm/clang to 3.2 release.

Release notes for llvm:
http://llvm.org/releases/3.2/docs/ReleaseNotes.html

Release notes for clang:
http://llvm.org/releases/3.2/tools/clang/docs/ReleaseNotes.html

MFC after:	2 weeks

------------------------------------------------------------------------
r244598 | dim | 2012-12-22 21:16:21 +0100 (Sat, 22 Dec 2012) | 16 lines

Pull in r170353 from upstream llvm trunk:

  Fix another SROA crasher, PR14601.

  This was a silly oversight, we weren't pruning allocas which were used
  by variable-length memory intrinsics from the set that could be widened
  and promoted as integers. Fix that.

This should fix the following assertion failure:

  Assertion failed: (CanSROA), function visitUsers, file
  /usr/src/lib/clang/libllvmscalaropts/../../../contrib/llvm/lib/Transforms/Scalar/SROA.cpp,
  line 2395.

Reported by:	gerald