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)

On Wed, Nov 6, 2013 at 12:42 PM, Jakub Jelinek <> 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?


>         Jakub

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