Re: Clang as default compiler November 4th

On Tue, Sep 11, 2012 at 01:45:18PM +0300, Konstantin Belousov wrote:
> On Mon, Sep 10, 2012 at 04:12:07PM -0500, Brooks Davis wrote:
> > For the past several years we've been working towards migrating from
> > GCC to Clang/LLVM as our default compiler.  We intend to ship FreeBSD
> > 10.0 with Clang as the default compiler on i386 and amd64 platforms.  To
> > this end, we will make WITH_CLANG_IS_CC the default on i386 and amd64
> > platforms on November 4th.
> > 
> > What does the mean to you?
> > 
> >  * When you build world after the default is changed /usr/bin/cc, cpp, and
> >    c++ will be links to clang.
> > 
> >  * This means the initial phase of buildworld and "old style" kernel
> >    compilation will use clang instead of gcc.  This is known to work.
> > 
> >  * It also means that ports will build with clang by default.  A major
> >    of ports work, but a significant number are broken or blocked by
> >    broken ports. For more information see:
> >      http://wiki.freebsd.org/PortsAndClang
> > 
> > What issues remain?
> > 
> >  * The gcc->clang transition currently requires setting CC, CXX, and CPP
> >    in addition to WITH_CLANG_IS_CC.  I will post a patch to toolchain_at_
> >    to address this shortly.
> > 
> >  * Ports compiler selection infrastructure is still under development.
> > 
> >  * Some ports could build with clang with appropriate tweaks.
> > 
> > What can you do to help?
> > 
> >  * Switch (some of) your systems.  Early adoption can help us find bugs.
> > 
> >  * Fix ports to build with clang.  If you don't have a clang system, you
> >    can use the CLANG/amd64 or CLANG/i386 build environments on
> >    redports.org.
> > 
> > tl;dr: Clang will become the default compiler for x86 architectures on 2012-11-04
> 
> There was a chorus of voices talking about ports already. My POV
> is that suggesting to 'fix remaining ports to work with clang' is
> just a nonsense. You are proposing to fork the development of all the
> programs which do not compile with clang. Often, upstream developers
> do not care about clang at all since it not being default compiler in
> Debian/Fedora/Whatever Linux. The project simply do not have resources
> to maintain the fork of 20K programs.

I may have phrased the above poorly, but in most cases I'd be happy with
using USE_GCC as a solution, but to the extent that port maintainers
can fix their ports to build with clang, that's a good thing.  Having a
deadline will help focus efforts towards finding the right fix for the
most important ports in a timely manner.

If we near the deadline and find that we need a few more weeks, nothing
prevents us from slipping the date a bit.

> Another issue with the switch, which seems to be not only not addressed,
> but even not talked about, is the performance impact of the change. I
> do not remember any measurements, whatever silly they could be, of the
> performance change by the compiler switch. We often have serious and
> argumented push-back for kernel changes that give as low as 2-3% of
> the speed hit. What are the numbers for clang change, any numbers ?

Florian Smeets (flo) did one round of benchmarks back in June with
sysbench/mysql.  There is a small but measurable slowdown both with
world compiled with clang and with mysql compiled with clang.  You can
see the results on the last page of this document:

http://people.freebsd.org/~flo/perf.pdf

The total impacts are on the order of 1-2%.  That's more than I'd like
and I expect some pushback, but I feel it is in the range of acceptable
code debt to take on to accomplish a multi-year project goal.

-- Brooks