Llvm full port?

1

Hello, freeBSD have pass to llvm because it become to be stable, quick to compile and hve performance.
I wish know if have any plan to pass to llvm (not just port, but replacing gcc)?

2

I think there is interest in it. At the moment it will have to wait until after 1.0, it does need someone to start working on it though.

3

There has been some discussion about using llvm/clang post R1. IIRC clang is not completely successful building all of the Haiku src, atm. It would be nice to use a compiler other than GCC, but currently llvm/clang does not supply a complete replacement.

4

EKOPath would be an interesting try…
Obviously it could be an heresy, don’t know :smiley:

5

LLVM is faster in compiling but the generated code is less performant than that of GCC. It might be a suitable substitute for GCC once it reaches more compability, as it stands it still fails to compile a large amount of widely used open source projects. Best of both worlds is if Haiku eventually offers both compilers and allow the end-user to choose according to his/her preference.

That said there are probably alot more important things to focus on for the Haiku devs than alternative compiler toolchains.

6

[quote=franz1789]EKOPath would be an interesting try…
Obviously it could be an heresy, don’t know :D[/quote]
Well it recently switched to open source (atleast it’s in transition) and is said to generate very optimized code. However it’s targeted at 64-bit only, and Haiku is currently (and in the foreseeable future) 32-bit only.

7

My understanding is that the reason for many oss projects not compiling with clang, is that gcc has many extentions not part of the C/C++ spec, and also allows for questionable code, which clang does not. If fact, clang has found many “gcc-isms” in the Haiku src. Several parts of Haiku would have to be fixed to be closer to the spec and not gcc, for clang to successfully build Haiku.

[quote]
That said there are probably alot more important things to focus on for the Haiku devs than alternative compiler toolchains.[/quote]

Indeed.

8

[quote=Disreali]
My understanding is that the reason for many oss projects not compiling with clang, is that gcc has many extentions not part of the C/C++ spec,[/quote]
Yes, the compiler extensions were mainly added at the requests of Linux kernel devs, many of which gives better control of final code generation (like branch prediction, cache locality etc) and the usefulness of these extensions have in turn resulted in them being used outside kernel development. So obviously in order for Clang/LLVM to be anywhere near compatible with GCC, the most used of these extensions will have to be supported.

[quote=Disreali]
and also allows for questionable code, which clang does not. If fact, clang has found many “gcc-isms” in the Haiku src.[/quote]
Well, all compilers allow ‘questionable’ code in one way or another since this is rooted in interpretation. As such there are obviously Clang’isms aswell. Most compilers allow you to set flags which result in stricter enforcement of given specs, many projects do not use these flags which is often the cause of compability problems as it opens up a realm of ‘interpretation’ which may differ from compiler to compiler but this also exists even within enforced specs.

It doesn’t really matter which compiler you use, GCC, Clang/LLVM, ICC, Visual Studio etc. Develop a project against either of these compilers and then recompile it against one of the others. If you are extremely lucky you will get away with only warnings. The more complex the code the more likely you are to come across errors due to interpretative/assumative differences, and kernels/operating systems certainly are complex.

9

There’s an interesting development on the clang front. CERN has a C++ interpreter built on top of clang called cling. It’s a C++ interpreter which could be beneficial to users if they want to experiment with building portions of user interfaces on-the-fly.

I followed the download / patch directions on this page to setup cling on a 3.1 llvm codebase:

http://solarianprogrammer.com/2012/09/02/building-cling-cpp-interpreter-windows/

I was able to successfully compile everything with (from memory) 2 mods:

  1. Hack: create a directory called /usr/bin and then “ln -s /boot/system/bin/env .”. I know. I know. The correct thing to do is to dig into the config file and test for a Haiku install and then setup the proper path for the env program.

  2. In the file, llvm/tools/cling/lib/UserInterface/textinput/TerminalConfigUnix.h, enter the following lines where the existence of sig_t is being checked on other platforms (near the top of the file):

#if defined(HAIKU)
typedef __sighandler_t sig_t;
#endif

I think that’s all I had to do and the entire llvm 3.1 package along with cling compiled with no problems. That’s the good news. [hmm, I still haven’t figured out how to run the regression tests properly…seems to involve Python and that messed up (with Haiku’s python port when I tried from the toplevel make file]

I think the bad news is that all the libraries would have to be built with llvm so that cling could use them.

Just thought I’d bring it up in case those of you with far more knowledge of the Haiku build system than I would be interested in getting the libraries recompiled with llvm…if only for the sole purpose of being able to use cling.

Here’s a nice vid by one of the cling developers from CERN:

10

[quote=Disreali]

My understanding is that the reason for many oss projects not compiling with clang, is that gcc has many extentions not part of the C/C++ spec, and also allows for questionable code, which clang does not. If fact, clang has found many “gcc-isms” in the Haiku src. Several parts of Haiku would have to be fixed to be closer to the spec and not gcc, for clang to successfully build Haiku.[/quote]

Seems to me that this is a good idea to do after the release of R1.

11

Regardless of when, it’s probably a good idea to follow in FreeBSD’s footsteps and eventually lose the GNU Toolchain.

1 Like
12

As I understand it LLVM and gcc are fairly evenly matched in terms of performance of the output code… gcc performing better in some tests and llvm better in others. But llvm always compiles faster and uses less memory during compilation. Though I understand the most recent versions of gcc are a little bit of a step up in performance so this may have changed somewhat, but probably in 6 months LLVM will get a boost too.

13

Indeed, LLVM and gcc are more matched in speed of object code. I heard from a ESA (European Space Agency) project that the speed of object code differed significantly only for numerical code, like matrix multiplication, etc. for large data sets.

14

I searched for ABI compatibility between clang and gcc 4.x and, from what I found, they are compatible. That would mean that if clang 3.1 / cling run correctly, cling should be able to link in Haiku’s gcc 4 shared libraries. So, no recompile of the existing libraries with clang to have a working C++ interpreter on Haiku. Pretty cool.

15

yes, clang 3.1 made very good progress, and now they are nearly equal with gcc when it comes to performance.
I guess it could be a good try, to try to deliver haiku-hybrid with gcc2 and clang (instead of gcc4).
But I dont know much about compilers, and I’m not sure, if the haiku developers aren’t afraid that the switch wouldn’t go that smooth.
And since the devs know gcc much better than clang, I guess they wouldn’t like to switch to clang too early.

perhaps this subject could/should be discussed on the mailing list.
I remember it was once discussed on the mailing list, something related to clang, but I forgot what it was about, and if there were some conclusions