This is the mail archive of the gcc-patches@gcc.gnu.org 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] Allow lazy construction of hash_{table,set,map}


On 3/21/19 1:48 PM, Jakub Jelinek wrote:
On Thu, Mar 21, 2019 at 10:25:25AM -0400, Jason Merrill wrote:
Attached (so far without changelog, selftest additions and only tested with
make -j32 -k check-c++-all RUNTESTFLAGS="dg.exp='pr89767.C *lambda* *desig*'"
) is
1) hash_{table,set} <whatever, true> implementation for lazy allocation

I would expect that a single test on an object that's already in cache in
the context of hash table operations would be insignificant, but if you

Some hash table operations are in performance sensitive code and even if
those checks wouldn't take too long, it would grow I-cache.

really want to offer that choice this seems like a clean enough way to
implement it.  Are you sure that we want the default to be immediate
allocation?

There are many that do want immediate allocation, so changing the default
looks way too risky to me.

2) the PR c++/89767 patch with optimization for zero and one entries
3) incremental PR c++/71446 fix to simplify that code using this new
     infrastructure

2 and 3 are explicitly specifying "false" for the Lazy parameter, which is
the default.

Ugh, thanks for spotting that.  Tests passed with that, and I only went
through in a debugger the earlier version with EMPTY_HASH.

We might do the duplicate checking in a wrapper around add_capture since
it's only used by cp_parser_lambda_introducer.  It's fine either way.

Looks like a good idea to me.

Attached are new versions of all the 3 patches.
1) now has ChangeLog and hash-set-selftest.c coverage
2) has the false -> true fixed
3) ditto, but furthermore is moved out of add_capture into the lambda
introducer parsing routine only, tests for [this, this] and [this, *this]
etc. are done using LAMBDA_EXPR_THIS_CAPTURE and the duplicate check for
capture_id is simplified too.

OK.

Jason


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