On Sep 4, 2013, at 7:09 AM, Jan Hubicka wrote:
> Making gengtype to generate ggc_mark for each type would make hand writting
> easier - you can use C++ overloading instead of trying to guess the funny
> names gengtype uses right now.
> But that is independent of this change. I am slowly getting u
> On Mon, 2013-09-02 at 14:35 +0200, Martin Jambor wrote:
> > Hi,
> >
> > On Fri, Aug 30, 2013 at 03:21:22PM -0400, David Malcolm wrote:
> > > Apart from the GTY aspect, how do people feel about the patch series?
> > > FWIW I have vague thoughts about doing something similar for tree -
> > > doing
Hi,
On Tue, 3 Sep 2013, David Malcolm wrote:
> > I can't really say I find this shorter, easier to read, more
> > expressive or even safer than what was there before. And the
> > repetition for adding the helpers for const and non-const types
> > all the time doesn't make it bet
On Mon, 2013-09-02 at 14:35 +0200, Martin Jambor wrote:
> Hi,
>
> On Fri, Aug 30, 2013 at 03:21:22PM -0400, David Malcolm wrote:
> > Apart from the GTY aspect, how do people feel about the patch series?
> > FWIW I have vague thoughts about doing something similar for tree -
> > doing so *might* gi
On Mon, 2013-09-02 at 13:44 +0200, Michael Matz wrote:
> Hi,
>
> On Fri, 30 Aug 2013, David Malcolm wrote:
>
[...]
> > > And the manual GTY markers are so not maintainable in the long run,
> > > gengtype or something else really needs to be taught to create them
> > > automatically.
> >
> > Ap
On Mon, 2013-09-02 at 13:44 +0200, Michael Matz wrote:
> Hi,
>
> On Fri, 30 Aug 2013, David Malcolm wrote:
>
> > Here's the result of a pair of builds of r202029 without and with the
> > patches, configured with --enable-checking=release, running "make", then
> > stripping debuginfo [1]
> >
> >
Hi,
On Fri, Aug 30, 2013 at 03:21:22PM -0400, David Malcolm wrote:
> Apart from the GTY aspect, how do people feel about the patch series?
> FWIW I have vague thoughts about doing something similar for tree -
> doing so *might* give an easier route to the type vs expression
> separation that Andre
Hi,
On Fri, 30 Aug 2013, David Malcolm wrote:
> Here's the result of a pair of builds of r202029 without and with the
> patches, configured with --enable-checking=release, running "make", then
> stripping debuginfo [1]
>
> So the overall sizes of such binaries are essentially unchanged.
Yep, co
On Sat, Aug 31, 2013 at 5:57 AM, Richard Biener
wrote:
> What do you do during stage1? Have a collector that never collects?
Yes. That was the pebble in the shoe. The cc1plus built for the
purposes of gengtype does not need to look at a lot of code, so
turning off collection may not be a big
On Sat, 2013-08-31 at 11:57 +0200, Richard Biener wrote:
> Diego Novillo wrote:
> >
> >Yes. Lawrence and I thought about moving gengtype inside g++. That
> >seemed like a promising approach.
>
>
> What do you do during stage1? Have a collector that never collects?
We could imagine that the s
Diego Novillo wrote:
>On Fri, Aug 30, 2013 at 11:37 AM, Jakub Jelinek
>wrote:
>
>> Teaching the gengtype parser about
>> {struct,class} name : public {struct,class} someothername { ... }
>> as opposed to current
>> {struct,class} name { ... }
>> shouldn't be that hard. And, if the complaint is t
Jakub Jelinek wrote:
>On Fri, Aug 30, 2013 at 11:28:34AM -0400, Diego Novillo wrote:
>> > Well, it was a wrong decision then. For some smaller types writing
>manual
>> > marker might be a sensible thing, or for some extra complicated
>> > constructs. But here we're talking about the most simple
On Thu, 2013-08-29 at 12:20 -0400, David Malcolm wrote:
[...]
> Successfully bootstrapped and tested on x86_64-unknown-linux-gnu: all
> testcases show the same results as an unpatched build (relative to
> r202029).
I messed up the testing for this by accidentally configuring the builds
with --ena
On Fri, 2013-08-30 at 15:44 +0200, Michael Matz wrote:
> Hi,
>
> On Thu, 29 Aug 2013, David Malcolm wrote:
>
> > Successfully bootstrapped and tested on x86_64-unknown-linux-gnu: all
> > testcases show the same results as an unpatched build (relative to
> > r202029).
>
> I'd like to see some sta
On Fri, Aug 30, 2013 at 11:28:34AM -0400, Diego Novillo wrote:
> > Well, it was a wrong decision then. For some smaller types writing manual
> > marker might be a sensible thing, or for some extra complicated
> > constructs. But here we're talking about the most simple struct hierarchy
> > imagin
On Fri, Aug 30, 2013 at 10:37 AM, Jakub Jelinek wrote:
> On Fri, Aug 30, 2013 at 11:28:34AM -0400, Diego Novillo wrote:
>> > Well, it was a wrong decision then. For some smaller types writing manual
>> > marker might be a sensible thing, or for some extra complicated
>> > constructs. But here we
On Fri, Aug 30, 2013 at 11:37 AM, Jakub Jelinek wrote:
> Teaching the gengtype parser about
> {struct,class} name : public {struct,class} someothername { ... }
> as opposed to current
> {struct,class} name { ... }
> shouldn't be that hard. And, if the complaint is that we'd need to write
> whole
On Fri, Aug 30, 2013 at 11:21 AM, Michael Matz wrote:
>
> Hi,
>
> On Fri, 30 Aug 2013, Gabriel Dos Reis wrote:
>
> > On Fri, Aug 30, 2013 at 9:02 AM, Jakub Jelinek wrote:
> >
> > >> I thought the principle that was acquired was that gengtype shouldn't
> > >> be improved to support more than what
On Fri, Aug 30, 2013 at 10:21 AM, Michael Matz wrote:
> Hi,
>
> On Fri, 30 Aug 2013, Gabriel Dos Reis wrote:
>
>> On Fri, Aug 30, 2013 at 9:02 AM, Jakub Jelinek wrote:
>>
>> >> I thought the principle that was acquired was that gengtype shouldn't
>> >> be improved to support more than what it doe
Hi,
On Fri, 30 Aug 2013, Gabriel Dos Reis wrote:
> On Fri, Aug 30, 2013 at 9:02 AM, Jakub Jelinek wrote:
>
> >> I thought the principle that was acquired was that gengtype shouldn't
> >> be improved to support more than what it does now….
> >
> > If it means that we'll need to write and maintai
On Fri, 2013-08-30 at 09:12 -0500, Gabriel Dos Reis wrote:
> On Fri, Aug 30, 2013 at 9:02 AM, Jakub Jelinek wrote:
> > On Fri, Aug 30, 2013 at 08:58:43AM -0500, Gabriel Dos Reis wrote:
> >> On Fri, Aug 30, 2013 at 8:44 AM, Michael Matz wrote:
> >>
> >> > And the manual GTY markers are so not main
On Fri, Aug 30, 2013 at 9:02 AM, Jakub Jelinek wrote:
> On Fri, Aug 30, 2013 at 08:58:43AM -0500, Gabriel Dos Reis wrote:
>> On Fri, Aug 30, 2013 at 8:44 AM, Michael Matz wrote:
>>
>> > And the manual GTY markers are so not maintainable in the long run,
>> > gengtype or something else really need
On Fri, Aug 30, 2013 at 08:58:43AM -0500, Gabriel Dos Reis wrote:
> On Fri, Aug 30, 2013 at 8:44 AM, Michael Matz wrote:
>
> > And the manual GTY markers are so not maintainable in the long run,
> > gengtype or something else really needs to be taught to create them
> > automatically.
>
> I thou
On Fri, Aug 30, 2013 at 8:44 AM, Michael Matz wrote:
> And the manual GTY markers are so not maintainable in the long run,
> gengtype or something else really needs to be taught to create them
> automatically.
I thought the principle that was acquired was that gengtype shouldn't
be improved to s
Hi,
On Thu, 29 Aug 2013, David Malcolm wrote:
> Successfully bootstrapped and tested on x86_64-unknown-linux-gnu: all
> testcases show the same results as an unpatched build (relative to
> r202029).
I'd like to see some statistics for cc1{,plus} codesize and for compile
time of something reason
The various gimple types are currently implemented using a hand-coded
C inheritance scheme, with a "union gimple_statement_d" holding the
various possible structs for a statement.
The following series of patches convert it to a C++ class
hierarchy, using the existing structs, eliminating the union
26 matches
Mail list logo
