On Wed, 13 Nov 2013, Jeff Law wrote: > On 11/13/13 08:59, Joseph S. Myers wrote: > > On Wed, 13 Nov 2013, Steven Bosscher wrote: > > > > > Really the best place to start IMHO would be to evict 'tree' from the > > > front ends. That would really be a step towards making the front ends > > > independent of the rest of the compiler, and it would simplify changes > > > towards static 'tree' types. > > > > From a C perspective, a useful change that would facilitate moving the IR > > away from tree would be moving most of fold to operate on GIMPLE instead > > of on trees (that is, rewriting it as GIMPLE optimizations; I don't think > > this can be a mechanical refactoring). > [ ... ] > Yes. That is most certainly part of "the plan". Andrew, myself and others > have discussed it extensively. It's a lot of work, but getting the tree > folder disentangled from the gimple optimizers is definitely on the hit list.
Note that *removing* things from the tree folder (and convert.c, and shorten_compare, and shorten_binary_op, and any other such fold-like things) once they've been moved to GIMPLE is a critical part of making it easier to clean up front-end IR; having them in both places won't help. -- Joseph S. Myers jos...@codesourcery.com
