This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: Richard Biener <richard dot guenther at gmail dot com>, Bernd Schmidt <bernds at codesourcery dot com>, Jeff Law <law at redhat dot com>, David Malcolm <dmalcolm at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Sun, 10 Nov 2013 11:18:37 +0000
- Subject: Re: [PATCH 0/6] Conversion of gimple types to C++ inheritance (v3)
- Authentication-results: sourceware.org; auth=none
- References: <5271CBF9 dot 2070005 at redhat dot com> <1383236801-13234-1-git-send-email-dmalcolm at redhat dot com> <527960A8 dot 7030107 at redhat dot com> <CAFiYyc2okBUaSpm61XkeNv04ps4oofRcqu5G0yFmYhAs6FYzqg at mail dot gmail dot com> <527A21DB dot 301 at codesourcery dot com> <CAFiYyc0aX4a_oO_EPogK3V_4Pyp=Et+q7+jb_wgEbt5s8yfxyA at mail dot gmail dot com> <527AACE6 dot 3040005 at redhat dot com>
Andrew MacLeod <email@example.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.