On Wed, Nov 13, 2013 at 5:50 PM, Jakub Jelinek <ja...@redhat.com> wrote: > On Wed, Nov 13, 2013 at 04:43:45PM +0000, Joseph S. Myers wrote: >> 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. > > Richard B. had the idea of generating parts of fold-const and corresponding > GIMPLE ops from some meta definition file.
Yeah, I hope to tackle the fold-const.c vs. GIMPLE mess during stage3 when everyone else is fixing bugs. (haha) Richard. > Note, in many cases, removing optimizations from fold-const.c leads to > regressions on code assuming something is folded (especially in > initializers). Sure, that is all typically undocumented GNU extensions, > but we had several such problems in the past already. > Jakub
