Thank you for the information!

So it sounds like right now, I could use 4.6.0 (4.7.0?), and be 
architecture-independent between processors of the same type. Like, code could 
be compiled to GIMPLE with no optimization for generic x86, then optimized and 
linked differently depending on the target processor, say for a 80386 and a 
core2, as long as the memory layout is the same. Would this work? This is still 
really good!
I have read what has been written about GIMPLE, on the website, I have not yet 
read the code. Is there any other documentation which would be useful to read?

How hard would it be to make GIMPLE fully architecture-independent? Could 
placement of items in memory be handled by the linker, and everything before 
linking be symbolically referenced? Sorry this is a pretty general question, 
and I haven't looked at the code, is this within the realm of possibility? 
Other than sizes of types and memory layout, what is architecture-dependent in 
GIMPLE?

Pretty stable is good enough, if gcc could be upgraded through a minor version 
or two, or bugfix patched, without the need to recompile everything, that would 
be great! On a major release of the distribution, everything would be 
recompiled anyways, so it doesn't matter if the GIMPLE format changes.

Rob

--- On Mon, 5/30/11, Richard Guenther <richard.guent...@gmail.com> wrote:

> From: Richard Guenther <richard.guent...@gmail.com>
> Subject: Re: WHOPR Linux distribution
> To: "Robert Beeporbop" <rbeepor...@yahoo.com>
> Cc: gcc@gcc.gnu.org
> Date: Monday, May 30, 2011, 3:35 AM
> 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
> >
>

Reply via email to