Quoting Richard Guenther <richard.guent...@gmail.com>:
What's the benefit of not including tm.h in the tree optimizers and frontend
files to our users?
We should see less instability of frontends and tree optimizers for less-often
tested targets. This can prevent release cycles from getting longer, and/or
allow more work to be accomplished in a release cycle.
These files should compile the same for different target configurations
(assuming we don't have a BITS_PER_UNIT discrepancy).
With tm.h included, you can never quite tell what's going on.
(unless you want to analyze every every source file for every target
configuration - that can be done in finite time, but not necessarily
before the code is obsolete.)
So you should be able to build the frontend once and use it in
multiple compilers, e.g. a native one and across-compiler to a netbook
with uses
a different processor.
More importantly, CPU-GPU programming certainly coming, and a multi-target
compiler should eventuallyprovide a tool to use such a heterogenous system
without having to do all the partitioning and interworking by hand.
