Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)

[Richard Biener <richard dot guenther at gmail dot com>]

Richard Sandiford <rdsandiford@googlemail.com> wrote:
>Andrew MacLeod <amacleod@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