On 11/13/13 09:43, 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.
Yup, absolutely.
Kai had the idea that this might make a good GSOC project. Take a
transformation in fold-const.c, move it into gimple. Evaluate over body
of code to verify we haven't regressed, if no regressions, submit.
Repeat until GSOC time is up.
It's not the most sexy work, but it comes out in bite sized hunks and
anything they get done stands on its own and helps the overall goal of
reducing the amount of unnecessary folding done in fold-const.c
jeff
