On Mon, May 30, 2011 at 12:10 PM, Robert Beeporbop <rbeepor...@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 >
