llvm dev - Apr 2016 - Question about compiler-rt builtins targets

Hi,

Short version: Is it possible to enable *all* builtins architectures? How?

Longer explanation:
I don't quite understand how compiler-rt targets are decided to be
built while invoking cmake from the LLVM tree.

I tend to believe that builtins and sanitizers (the two big parts in
compiler-rt) are quite different monsters, but however they share the
same build decisions and (if I'm not mistaken) they're built for the
same set of targets. This seems to be somewhat inconvenient, because I
want that my clang binary had builtins support for all the targets I
enabled, and not only for those that have sanitizers support on the
host machine.

I disabled sanitizers in my build because they're quite difficult to
compile in older OSs (so I invoke cmake with
-DCOMPILER_RT_BUILD_SANITIZERS=OFF), but however, when invoking cmake,
it's telling me that compiler-rt is targeting i386 and x86_64. No
mention of the rest of LLVM targets I'm building.

How can I get builtins for all architectures that have builtins support?

Thanks!

Hi Ardi,


I know this email is old and that I replied to your other email already, but I
wanted to respond to this email too. Unfortunately you sent these emails while I
was out of town and I’m just now catching up.

The CMake build system for compiler-rt is in the middle of a massive overhaul,
and unfortunately I haven’t had as much time as I’d like to finish it off.
Hopefully I’ll be getting the time to finish it off soon. Let me give you the
high level view of where it is going.

The next big thing I’m trying to land is a restructuring of compiler-rt to
logically separate the builtins and the sanitizer runtimes. I sent out a really
early set of patches for this a while back you can find them here
(http://reviews.llvm.org/D16653 <http://reviews.llvm.org/D16653>).

Once I finish that work, the next thing I’m going to be working on is
overhauling how the LLVM build system interfaces with compiler-rt’s build.
Today, when you build compiler-rt as part of LLVM it builds in one of two ways.
The default (which is almost always wrong) is to build it using the host
compiler and targeting the host. The alternative (by specifying
-DLLVM_BUILD_EXTERNAL_COMPILER_RT=On to CMake) uses the just-built clang and
targets the host, is at least sometimes right.

The problem is you actually may want to build compiler-rt more than once. To
solve that problem we want to be able to specify a list of targets that can be
passed to the LLVM build during configuration, which will tell compiler-rt which
targets to build the builtins and sanitizers for. We also want to extend that
mechanism to building libcxxabi, libcxx, and libunwind.

I’m really hoping to have most of this work done before the LLVM 3.9 release,
but I might not get it done in time. It will mostly depend on how much my boss
(and his boss) distract me. Since we’re all ADHD squirrels that could be a lot.

I mostly want you to know that I feel your pain, and there is actually effort
being put in to fix it.

The other thing I wanted to touch on is you mentioned in your email you think
there is a disconnect in mindset. I think you’re misunderstanding. The LLVM
community supports very old OS versions. In fact, we still use CMake 2.8.12
because that’s what comes on the Ubuntu 14.04 LTS. I suspect we’ll be moving off
that soon as there is a new LTS release imminent, but we generally support
developing on 2-3 year old OS releases, and deploying to even older releases. As
an example, in our coding standards document
(http://llvm.org/docs/CodingStandards.html#supported-c-11-language-and-library-features
<http://llvm.org/docs/CodingStandards.html>) we list a significantly
limited set of C++11 features that we allow in LLVM code. That list is catered
based on supporting building with 3-5 year old compilers and running on some
pretty old OS releases. In fact we just dropped running on Windows Vista and XP
with the 3.8 release.

One of the complications with supporting old OS releases is that they aren’t
always as well tested as the newer releases, and sometimes they get bugs that
linger for a long time because none of the core developers really care. If there
are bugs impacting your ability to use an older OS or toolchain, we will always
accept patches to fix them as long as they’re reasonable and don’t introduce
undue burden to the community (i.e. we’re not going to stop using C++11 because
someone wants to support building with GCC 4.2).

If there are bugs preventing you from using clang on OS releases that are fairly
modern but not cutting edge I’d encourage you to file bugs on our bug tracker
(https://llvm.org/bugs/ <https://llvm.org/bugs/>). Our community is
committed to making Clang the best open source compiler around, and we generally
hate it when users feel discouraged about our project.

Thanks,
-Chris

> On Apr 14, 2016, at 9:25 AM, ardi via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hi,
> 
> Short version: Is it possible to enable *all* builtins architectures? How?
> 
> Longer explanation:
> I don't quite understand how compiler-rt targets are decided to be
> built while invoking cmake from the LLVM tree.
> 
> I tend to believe that builtins and sanitizers (the two big parts in
> compiler-rt) are quite different monsters, but however they share the
> same build decisions and (if I'm not mistaken) they're built for
the
> same set of targets. This seems to be somewhat inconvenient, because I
> want that my clang binary had builtins support for all the targets I
> enabled, and not only for those that have sanitizers support on the
> host machine.
> 
> I disabled sanitizers in my build because they're quite difficult to
> compile in older OSs (so I invoke cmake with
> -DCOMPILER_RT_BUILD_SANITIZERS=OFF), but however, when invoking cmake,
> it's telling me that compiler-rt is targeting i386 and x86_64. No
> mention of the rest of LLVM targets I'm building.
> 
> How can I get builtins for all architectures that have builtins support?
> 
> Thanks!
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160426/6fd70bdc/attachment.html>

On Wed, Apr 27, 2016 at 4:15 AM, Chris Bieneman via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> The other thing I wanted to touch on is you mentioned in your email you
> think there is a disconnect in mindset. I think you’re misunderstanding.
> The LLVM community supports very old OS versions. In fact, we still use
> CMake 2.8.12 because that’s what comes on the Ubuntu 14.04 LTS. I suspect
> we’ll be moving off that soon as there is a new LTS release imminent, but
> we generally support developing on 2-3 year old OS releases, and deploying
> to even older releases.
>
The version ardi is targeting, OS X 10.6.8, is quite a bit older than that
:-) 10.6 came out in 2009, and the .8 final release in mid 2011. However a
significant number of machines have not been upgraded past it for the
rather annoying reason that it's the last one that supports the built in
"Rosetta" PowerPC emulator. Systems supported by 10.6.8 include
reasonably
modern ones such as the quad core Nehalem i7 17" laptop I'm typing this
on,
which is not a lot slower than the current models with Haswell. I've got
the latest OS on the aftermarket Samsung Pro SSD, but 10.6.8 is on the
original 750 GB hard disk and I can boot into it any time.

I think it's reasonable to say that an OS version is "supported"
in that
the various tools that come with it (or are readily downloadable) are good
enough to build current LLVM.

However, I don't see any reason that you should not be able to run a
compiler which, let's face it, primarily reads a few disk files and writes
other disk files, on anything Unix-like, no matter how old, provided that
the utility programs needed for the build process have already been
installed in a suitable version.

Of course you don't want to have to support system compilers that don't
do
C++11, but ardi has already gone to the trouble of making a working LLVM
3.5 for his 10.6.8 system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160427/babf2fe7/attachment.html>