On Wed, Nov 13, 2013 at 1:07 PM, Eric Botcazou <ebotca...@adacore.com> wrote: >> Eric, would emitting GIMPLE from gigi make that a lot more >> complicated? That is, would you prefer to have an even >> higher-level early GIMPLE (considering stuff like TARGET_EXPR >> and WITH_CLEANUP_EXPR, etc.)? > > This would mean privatizing in gigi all the machinery needed to support types > with variable size scattered over the middle-end (tree.c, fold-const.c and > stor-layout.c) unless you want to make them first-class citizens in GIMPLE, > which is very unlikely I presume. Not undoable, but IMO that would be a step > backwards from GENERIC in which you can express a lot a things, and not only > the semantics of C and its close relatives.
Yeah, that's why I am asking. I suppose you are refering to gimplify_type_sizes and the required lowering of ARRAY_REFs and COMPONENT_REFs? Yes, I'd not make them first class citizens in the GIMPLE that the optimizers see but I'm fine with having high-GIMPLE support for them, doing a lowering pass on GIMPLE. For a partial transition (that is, have frontends emitting GENERIC and frontends emitting GIMPLE) we'd split out these pieces into a 2nd "gimplification" stage and call its input very-high-GIMPLE ;) Do you see any benefits in emitting "high" GIMPLE (besides eventually some minor compile-time and memory-usage improvements)? That is, would some things be easier to do? [you'd also lose any folding that generating GENERIC would have done] Richard. > -- > Eric Botcazou
