On 3/20/19 10:48 AM, Jakub Jelinek wrote:
On Wed, Mar 20, 2019 at 10:34:51AM -0400, Nathan Sidwell wrote:
On 3/19/19 2:14 PM, Jakub Jelinek wrote:
add_capture when parsing a lambda introducer uses the IDENTIFIER_MARKED
bit to detect duplicate captures.
I guess in strict C++11 that could have worked, if the introducer could
contain just identifiers, but in C++14 it has 2 problems:
The following patch stops using IDENTIFIER_MARKED for this and uses a
hash_set instead. But, as I believe lambdas with 0 (or very few) explicit
captures are extremely common, I've tried not to slow down those with
allocation of a hash_set and deallocating it again, so it uses
a linear search if there are up to 8 captures and starts using a hash_set
only when getting above that count.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Or do you think allocation of an hash_set and deallocation would be in a
noise?
I think it'd be in the noise. The high bit is between zero and more than
zero captures. The next most common after zero would be 1. Besides,
identifiers are trivial to hash.
What I meant is that even just hash_set<tree> var; implies a xcalloc (13,
sizeof (void*)) or so and destroying it a free of that.
So, if 90% of all lambdas in the headers have zero captures and 5% have 1,
then simplifying the patch by adding that hash_set<tree> var; into the
lambda introducer parsing routine and just always using the hash set would
add those to the parsing of all those 95%+ lambda parsings that don't really
need that.
Here is attached completely untested variant that does that unconditional
xcalloc/free for every lambda introducer parsing.
I was unclear. I was for the lazy creation of the hash. I just think
it can be lazily created at either the first or second explicit capture.
nathan
--
Nathan Sidwell
