WHOPR Linux distribution

[Richard Guenther]

On Mon, May 30, 2011 at 12:10 PM, Robert Beeporbop <rbeeporbop@yahoo.com> wrote:
> Thanks to all the gcc developers!
>
> I am working on a Linux distribution which compiles all binaries statically at run-time with WHOPR. I hope to:
>
>  = Have everything running insanely fast. I did some testing with a couple programs using gcc 4.5 with WHOPR and other new optimizations, and compared to a few minor versions back, the binaries ran insanely fast, when they worked. There were some problems...
>  = Create a mostly architecture-independent distribution. I want the kernel, some of binutils, and gcc to be the only architecture-dependent components of the distribution. Compiled binaries would be cached.
>  = Not have a general purpose distribution, rather one suited towards high-performance computing and servers, which only run a limited set of pre-planned applications.
>
> I have some questions for the gcc developers:
>
>  ^ Do you have any tips, tricks, techniques, comments, or anything else to say about this? Is it do-able at this point, or should I wait (or help) with future releases? I started this with gcc 4.5, and there were some problems at that point in time.

I would suggest to at least move to GCC 4.6.

>  ^ Is there a way to compile code so that architecture-independent GIMPLE is produced? I have been using no optimization at all for my GIMPLE compiles, and it seems to me that it would produce architecture-independent GIMPLE. Would the final compile/link be possible for all x86's? Would optimizations at this point work as well as if they were done first? Would the same GIMPLE be able to be compiled/linked for, say, an ARM processor?

No, GIMPLE is architecture dependent as it contains for example
language ABI details (size of size_t, and structure layout for example).
So, architecture-independence isn't going to work in any way.

>  ^ It looks like GIMPLE is expected to change per version of gcc. Is there a time in the future when GIMPLE will be pretty stable?

"Pretty stable" won't be enough, and I don't see us arriving there at
the moment.

>  ^ It looks like there is some startup code in libgcc that is, and has to be, architecture-dependent. Are the other parts architecture-independent? Has anyone tried compiling libgcc statically with -flto, and doing a WHOPR link against it to produce a static binary?

See above.

>  ^ Is there a simple way to strip everything but GIMPLE from object files? I imagine that objcopy could do it. In the brief time I looked at it, the GIMPLE section layout looked pretty complicated.

We are working on that for GCC 4.7.

>  ^ Is there a way to compile gcc with only the GIMPLE frontend? It shows up in the configure script, could I configure with --enable-languages=gimple?

You can configure for c and lto only.

> Also, I had a couple other general development questions:
>
>  ~ LLVM appears to be able to use the gcc C compiler frontend and the LLVM backend. Has anyone been working on more integration between LLVM and gcc. It would be interesting to use the LLVM backend to optimize GIMPLE, then pass it back to gcc again for more optimization. Interesting in which way I do not know. Is there any possible or theoretical advantage to doing this?

I doubt so.

>  ~ Has anyone been working on GPU support, automatically-utilized or otherwise?
>  ~ Linaro gcc has a lot of good stuff implemented for ARM. Is Linaro gcc work being merged into gcc? I ask, because this brings back egcs memories.

Yes.

>  ~ I would like to play a game, where did the -fwhopr option go? I'm using -flto -fwhole-program now, is this the same? I still like -fwhopr, please bring it back!

-flto is the same as -fwhopr in 4.6 (old -flto can be activated by
-flto-partition=none in 4.6).  You do not need -fwhole-program if
you use a linker plugin (GNU ld > 2.21 or gold), and I would
stronly advise you to do that.  4.6 does so by default if at
configure time a suitable linker is detected.

Richard.

> Rob
>