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 Biener <richard dot guenther at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: 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>, Andrew MacLeod <amacleod at redhat dot com>
- Date: Wed, 6 Nov 2013 14:00:56 +0100
- 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> <20131106114253 dot GY27813 at tucnak dot zalov dot cz>
On Wed, Nov 6, 2013 at 12:42 PM, Jakub Jelinek <email@example.com> wrote:
> On Wed, Nov 06, 2013 at 12:31:00PM +0100, Richard Biener wrote:
>> > Maybe we need to revisit it? As one of those who were not in favour of
>> > the C++ move, can I ask you guys to step back for a moment and think
>> > about - what do all of these changes buy us, exactly? Imagine the state
>> > at the end, where everything is converted and supposedly the temporary
>> > ugliness is gone, what have we gained over the code as it is now?
>> as_a gains us less runtime checking and more static type checking
>> which is good.
> But that really affects --enable-checking=yes builds (and only cases where
> things aren't inlined). If the price for that is uglier and less readable
> code, then the price is just too high.
>> > I still think all this effort is misdirected and distracts us from
>> > making changes that improve gcc for its users.
>> That I agree to. Instead of fixing the less than optimal separation / boundary
>> between frontends and the middle-end, or fixing several other long-standing
>> issues with GCC we spend a lot of time refactoring things to be C++.
>> But that was kind of part of the decision (though I remember that we
>> mainly wanted to convert containters and isolated stuff, not gimple
>> or trees (I bet that'll be next)).
>> Of course I don't see contributors of "changes that improve gcc for its users"
>> now wasting their time with converting code to C++. That conversion
>> may slow down those people, but only so much. It'll get more interesting
>> with branch maintainance ...
> If the changes are done at least with some for users useful goal (like
> perhaps making gcc usable as a library for JITting etc.), then I can see
> the benefit, but as_s<> uglification doesn't seem to be beneficial to
> users at all, and IMNSHO much better would be to instead
> spend time on what is beneficial to users (restrict, vectorizer
> cost model, vectorizer improvements, better diagnostics (say range
> locations), ...).
Well, what else, besides as_a<> or keeping the current
global accessor functions would you propose?