On Mon, May 30, 2011 at 1:14 PM, Robert Beeporbop <rbeepor...@yahoo.com> wrote: > 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!
To some extent yes. When programs check feature availability based on preprocessor macros like __SSE2__ it of course can't (those are evaluated early). > 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? I don't think the information is useful for your case. > 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? It's impossible, already the language frontends expose some ABI details. > 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. I would expect that we try to remain compatible on a release branch. But given the lack of any automated way to detect if we break something there the guarantee is pretty low. Richard.
