This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Richard Sandiford <> wrote:
>Andrew MacLeod <> writes:
>> 2 - I really believe gimple needs a type system different from front
>> 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. 
>> a separate type system for gimple, we can rid ourselves of all the
>> 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
>> the front end tree types into a new or reduced-type subset, I might
>> well put that effort into something that is more appropriate right
>> 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.

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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]