Re: [PATCH] Fix PR c++/70452 (regression in C++ parsing performance)

2016-04-05 Thread Jason Merrill
OK, thanks. Jason

Re: [PATCH] Fix PR c++/70452 (regression in C++ parsing performance)

2016-04-04 Thread Patrick Palka
On Mon, 4 Apr 2016, Jason Merrill wrote: > On 04/02/2016 05:18 PM, Patrick Palka wrote: > > Here's a version that uses a separate deletable table to cache the > > function copies. For simplicity I used a hash_map instead of a > > hash_table. Does this look OK to commit after bootstrap + regtest?

Re: [PATCH] Fix PR c++/70452 (regression in C++ parsing performance)

2016-04-04 Thread Jason Merrill
On 04/02/2016 05:18 PM, Patrick Palka wrote: Here's a version that uses a separate deletable table to cache the function copies. For simplicity I used a hash_map instead of a hash_table. Does this look OK to commit after bootstrap + regtest? Thanks. Minor nits: > +struct fundef_copies_table

Re: [PATCH] Fix PR c++/70452 (regression in C++ parsing performance)

2016-04-03 Thread Patrick Palka
On Sat, Apr 2, 2016 at 11:57 PM, Trevor Saunders wrote: > On Sat, Apr 02, 2016 at 05:18:31PM -0400, Patrick Palka wrote: >> On Fri, 1 Apr 2016, Jason Merrill wrote: >> >> > I like this approach a lot. One thing, though: >> > >> > On 04/01/2016 03:13 PM, Patrick Palka wrote: >> > > +struct GTY((ch

Re: [PATCH] Fix PR c++/70452 (regression in C++ parsing performance)

2016-04-02 Thread Trevor Saunders
On Sat, Apr 02, 2016 at 05:18:31PM -0400, Patrick Palka wrote: > On Fri, 1 Apr 2016, Jason Merrill wrote: > > > I like this approach a lot. One thing, though: > > > > On 04/01/2016 03:13 PM, Patrick Palka wrote: > > > +struct GTY((chain_next ("%h.prev"))) bpr_entry > > > +{ > > > + tree body; >

Re: [PATCH] Fix PR c++/70452 (regression in C++ parsing performance)

2016-04-02 Thread Patrick Palka
On Fri, 1 Apr 2016, Jason Merrill wrote: > I like this approach a lot. One thing, though: > > On 04/01/2016 03:13 PM, Patrick Palka wrote: > > +struct GTY((chain_next ("%h.prev"))) bpr_entry > > +{ > > + tree body; > > + tree parms; > > + tree res; > > + struct bpr_entry *prev; > > +}; > > +

Re: [PATCH] Fix PR c++/70452 (regression in C++ parsing performance)

2016-04-01 Thread Patrick Palka
On Fri, Apr 1, 2016 at 9:54 PM, Patrick Palka wrote: > On Fri, Apr 1, 2016 at 9:28 PM, Jason Merrill wrote: >> I like this approach a lot. One thing, though: >> >> On 04/01/2016 03:13 PM, Patrick Palka wrote: >>> >>> +struct GTY((chain_next ("%h.prev"))) bpr_entry >>> +{ >>> + tree body; >>> +

Re: [PATCH] Fix PR c++/70452 (regression in C++ parsing performance)

2016-04-01 Thread Patrick Palka
On Fri, Apr 1, 2016 at 9:28 PM, Jason Merrill wrote: > I like this approach a lot. One thing, though: > > On 04/01/2016 03:13 PM, Patrick Palka wrote: >> >> +struct GTY((chain_next ("%h.prev"))) bpr_entry >> +{ >> + tree body; >> + tree parms; >> + tree res; >> + struct bpr_entry *prev; >> +}

Re: [PATCH] Fix PR c++/70452 (regression in C++ parsing performance)

2016-04-01 Thread Jason Merrill
I like this approach a lot. One thing, though: On 04/01/2016 03:13 PM, Patrick Palka wrote: +struct GTY((chain_next ("%h.prev"))) bpr_entry +{ + tree body; + tree parms; + tree res; + struct bpr_entry *prev; +}; + /* Representation of entries in the constexpr function definition table. *

Re: [PATCH] Fix PR c++/70452 (regression in C++ parsing performance)

2016-04-01 Thread Patrick Palka
On Fri, Apr 1, 2016 at 3:13 PM, Patrick Palka wrote: > Currently during constexpr CALL_EXPR evaluation we create a new copy of > the callee function's body for each separate call with no attempt made > at reusing the function body. So when a function ends up getting called > 10s of thousands of t