Re: [gentoo-dev] New project: LLVM

[Lei Zhang]

2016-08-20 1:13 GMT+08:00 C Bergström :
> I finally got it to build and here's the size numbers
> 952K./lib/libc++abi.a
> 616K./lib/libc++abi.so.1.0
>
> If the above isn't enough motivation and you really want benchmarks
> which prove it's a pig... I'll try to figure something else
>
> Not exactly a 1:1 comparison because I think other things are mixed in, but...
> 352K/usr/lib/gcc/x86_64-linux-gnu/4.9/libsupc++.a
> 356K/usr/lib/gcc/x86_64-linux-gnu/5/libsupc++.a
>
> In the land of HPC we frequently statically link stuff... not that
> 864KB is big by any sort of modern definition, but it does raise
> questions..

Though larger code size might be detrimental to performance (more
cache misses), seeing the runtime of a real world program is probably
more convincing :)

Speaking of HPC, could you recommend some HPC programs that I can
benchmark against libcxxrt/libc++abi?


Lei

Re: [gentoo-dev] New project: LLVM

[Lei Zhang]

2016-08-19 10:07 GMT+08:00  :
> That seems a lot like what we've already done. I guess a GSOC student is 
> working on the libcxxabi piece.

I am that GSoC student :)

I'm currently trying to push libc++abi to replace libcxxrt as the
default runtime: https://github.com/gentoo/gentoo/pull/2048

The reason is I think libc++abi blends in more naturally with other
LLVM components, and it has a clear version number as opposed to
libcxxrt.

> The only advantage to using our runtime, libcxxrt, is performance and code 
> size.‎

Honestly I don't know what essential difference these two libs have; I
can't find any decent comparison of them on the internet. Do you have
some real numbers to show the difference in performance and code size?


Lei

Re: [gentoo-dev] New project: LLVM

[Lei Zhang]

2016-08-18 21:56 GMT+08:00 C Bergström :
> @mgorny may be able to help with some of this and has quite a bit of
> experience building clang/llvm.  Where I work we use a "wrapper" that
> helps coordinate a lot of the moving pieces.
>
> https://github.com/pathscale/llvm-suite/
>
> This may not be the perfect "gentoo" way to handle it, but the
> approach would produce a clean and correct compiler. With llvm
> dependencies getting more and more complicated, I'm not sure if it
> would be possible to have both a gnu-free and also perfect
> 1-project-source-repo:1-ebuild ratio.

Currently the ebuilds for libunwind, libc++abi and libc++ all involve
some hackery to support standalone build. And the package clang is
just a placeholder, while it's actually built in llvm.

Maybe we can put them all into the llvm package, and control what
components to build via USE flags.


Lei

Re: [gentoo-dev] [RFC] new eselect module: compiler

[Lei Zhang]

2016-08-10 0:16 GMT+08:00 Zac Medico :
> I'm guessing you Darwin folks don't compile many Linux kernels? The last
> I heard, clang is not yet a drop-in replacement for gcc when building
> the Linux kernel:
>
> http://llvm.linuxfoundation.org/index.php/Main_Page

Yes, Linux kernel has to be built by gcc at the moment. Last time I
checked it, the kernel source is hardcoded to use gcc, so changing cc
won't affect it.

Other than the kernel, non-gcc compilers should work just fine in
userland. FWIW, I've tried rebuilding @world with clang on my host;
only two packages failed and they are very easy to fix [1].


[1] 
https://blogs.gentoo.org/gsoc2016-native-clang/2016/07/24/a-new-gentoo-stage4-musl-clang/

Lei

Re: [gentoo-dev] [RFC] new eselect module: compiler

[Lei Zhang]

2016-08-06 21:45 GMT+08:00 James Le Cuirot <ch...@gentoo.org>:
> On Thu, 28 Jul 2016 13:16:45 +0800
> Lei Zhang <zhanglei.ap...@gmail.com> wrote:
>
>> I'm proposing to offer a new eselect module "compiler". Briefly
>> speaking, it manages /usr/bin/{cc,c++} as symlinks to C/C++ compilers
>> specified by the user.
>
> I'm not on the toolchain team so I cannot comment much but be aware
> that there was previously an eselect module called "compiler". It was
> removed in 2007 because it did silly things. See this bug.
>
> https://bugs.gentoo.org/show_bug.cgi?id=199914
>
> I'm not suggesting that your version does silly things. :) I don't know
> how practical is it to swap "cc" with something other than gcc as I've
> never tried clang.

"cc" is the standard C compiler name defined in POSIX, so ideally any
gcc-agnostic programs should use "cc" instead of "gcc". Practically,
build tools like GNU Make and CMake would be affected as they use "cc"
implicitly.

OTOH, POSIX doesn't require the presence of C++ compiler on a
conformant system; "c++' is just a de facto standard.


Lei

[gentoo-dev] [RFC] new eselect module: compiler

[Lei Zhang]

Hi,

I'm proposing to offer a new eselect module "compiler". Briefly
speaking, it manages /usr/bin/{cc,c++} as symlinks to C/C++ compilers
specified by the user.

This is related to my GSoC project: to use clang as the native
compiler in Gentoo. While putting "CC=clang" in make.defaults could
make portage use clang, symlinking cc/c++ to clang allows build tools
like GNU Make and CMake to also use clang as the default compiler,
making it feel more "native".

This module should be orthogonal to gcc-config. It just switches
between gcc, clang or whatever compiler, and doesn't care what version
of gcc is in use. Currently gcc, clang and icc are supported in my
implementation.

Another two programs that might be of interest are /usr/bin/{c89,c99}.
Currently they are just scripts that invoke gcc with proper "-std=..."
option. I'm not sure if any build tools use them instead of cc. In
that case, they probably should be handled by `eselect compiler` as
well.

A side note: actually there's a small issue with GNU make and I'm
trying to fix it. Please refer to
https://bugs.gentoo.org/show_bug.cgi?id=589894 and
https://github.com/gentoo/gentoo/pull/1982


Lei


compiler.eselect
Description: Binary data

[gentoo-dev] [GSoC] Introduction

[Lei Zhang]

Hi Gentoo community,

My name is Lei Zhang, and I'm currently a master program student at Peking 
University, China.

I'm generally interested in system-level programming and have worked on several 
projects related to this area before. I also participated in GSoC last year 
contributing to John the Ripper, a password cracker.

After browsing Gentoo's GSoC ideas this year, I'm very interested in the "Clang 
native support" project. I already had some discussion with the mentor, Luca, 
and familiarized myself with the background of this project. I'm looking 
forward to working with you guys and making further progress on this project :)


Regards,
Lei