Andrew MacLeod <amacl...@redhat.com> writes: > 2 - I really believe gimple needs a type system different from front end > trees, that is my primary motivation. I'm tired of jumping through > hoops to do anything slightly different, and I got fed up with it. With > a separate type system for gimple, we can rid ourselves of all the stuff > that isn't related to optimization and codegen... Could we do this > with trees? possibly, but if I'm going to go to the effort of converting > the front end tree types into a new or reduced-type subset, I might as > well put that effort into something that is more appropriate right from > the start.
But what types specifically are you hoping to drop? Would there still be enough information for proper TBAA, for instance? Having two different type representations just sounds like it's going to lead to code duplication for common operations. Plus I'd really not like to see targets have to deal with two different representations of types. Sometimes the things that the target has to do only make sense "at the tree level" (e.g. providing the definition of va_list). Some are on the boundary, such as lowering va_arg into gimple. Some could potentially be used in both places, e.g. the hook to determine the correct alignment for a vector. (I can imagine we'd want to be able to call that at the tree level for user-defined vectors passed to __alignof, say, but also at the gimple level when vectorising.) Others are called during expand, e.g. PROMOTE_MODE. Thanks, Richard
