So is GCC adding a toolchain similar to the one LLVM has around its bitcode?
In this instance, a way to write a text representation of an internal data structure that represents code, run a single optimization pass over that data structure, dump the result, compare the result with serialized text representation of "expected value"?
Will they add the other parts, to extract an llvm-like core out of gcc and implement the C and C++ compilers and link time optimizer as users of that core?
> So is GCC adding a toolchain similar to the one LLVM has around its bitcode?
Not as far as I can tell.
> In this instance, a way to write a text representation of an internal data structure that represents code, run a single optimization pass over that data structure, dump the result, compare the result with serialized text representation of "expected value"?
That's already existed for ages. See the -fdump-tree-* family of functions. It also doesn't do anything llvm-like.
So all that hasn't existed for ages. Only dumping the intermediate representation has existed for ages, but not loading it and not running the middle-end of the compiler on the loaded IR.
Right, the historical problem with loading GIMPLE was that it still required all sorts of frontend specific bits.
Also, tons of things reused tons of bits for different purposes :)
Way the heck back when (pre-c++), i started splitting up just the decl hierarchy in trees to try to get things to stop reusing bits, and to expose what would be required to make it independent of the frontendy bits.
In this instance, a way to write a text representation of an internal data structure that represents code, run a single optimization pass over that data structure, dump the result, compare the result with serialized text representation of "expected value"?
Will they add the other parts, to extract an llvm-like core out of gcc and implement the C and C++ compilers and link time optimizer as users of that core?