3 ms·
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 structu
by wolf550e 10y ago
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?
- ori_b 10y ago> 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.
- wolf550e 10y agoSo 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.
- dmalcolm 10y ago[author of the post here] Correct: loading the IR dumps back in is new.
- DannyBee 10y agoRight, 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.