[clang] [llvm] DO NOT MERGE: Identify places that need reserve. (PR #136543)

[Jakub Kuderski via llvm-commits]

https://github.com/kuhar commented:

> I understand that you are working on improving the performance of llvm::append_range.

I'm interested and attempted to, but I have very few cycles these days (mostly weekends/holidays). The biggest blocker for me is setting up something I can quickly test locally. @nikic provided some instructions but I haven't had time to try that. Ideally, I'd like a large bitcode file I can wget and then a strict to run perf for me and give me the numbers back... I've done it before, using gllvm, and have a whole-program .bc for clang, but that bitcode is very old (from 5.0 era?) and probably not useful anymore.

I thought of a similar approach but slightly tweaked -- I left inline comments.

> I'm wondering if porting those reserve() calls on SmallPtrSet and such to your patch (https://github.com/llvm/llvm-project/pull/136365) might improve the performance. Also, I am wondering if your patch needs to deal with pointer ranges like char *, which I assume doesn't have an iterator category. Note that ArrayRef uses pointers as iterator types.

Iterator traits/categories should already handle raw pointers -- I don't think there's anything to do here.

The way I'd approach it would be deciding what compile time checks we need:
1. has_reserve (which you already have) -- otherwise we can't do much
2. has_fast_size (I'd rely on either `llvm::size` or `.size()` being present, with the assumption that `.size()` is fast)
3. has_capacity (like you have) -- for debugging/testing only

Then the remaining exercise would be adding .reserve to containers that can benefit from it and potentially removing/renaming `.size()` from types where it involves a slow query.

> 

https://github.com/llvm/llvm-project/pull/136543