Richard Sandiford <rdsandif...@googlemail.com> wrote: >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.
I can see that a change of the representation of types makes sense to better isolate frontend dependent things. In theory we have lang_type for that but frontend specific things are unfortunately not limited to that. That said, the idea of doing it on our own in gimple isn't the best - rather the existing tree representation should be changed and with it all affected frontends. Even with trees not all things need to remain trees btw, types could get a non-tree structure. But then start at the root of the problem that trees are ubiquitous - remove the remaining tree container structures and its uses. In the past a lot of work has already been done here, but it's not yet complete. Richard. >Thanks, >Richard
