[PATCH] Use Rvalue refs in APInt

[Matthias Braun via llvm-commits]

I've seen those APInt allocations being an actual compiletime problem as well. Back at the time I had the idea that we may be able to create APInt variants that allocate their data with a BumpPtrAllocator which we could store with the SCEV pass.. I never got around to actual work on that though.

- Matthias

> On May 31, 2016, at 6:06 PM, Pete Cooper via llvm-commits <llvm-commits at lists.llvm.org> wrote:
> 
> Hi David, Chandler
> 
> I’ve been measuring the number of allocations in LLVM and see millions of APInt’s in the trace.
> 
> The majority of the traces come from things like ConstantRange where its common to see expressions like 'this_max * Other_max + 1’ (from ConstantRange::multiply).
> 
> This patch attempts to reduce the number of allocations with r-value refs on expressions such as these.  Using the bitcode for verify-uselistorder, this reduces the total number of allocations with ‘opt -O2 verify-uselistorder’ from 19.5m to 19.1m.  
> 
> There are also compiler time wins to be had.  Before I started reducing the allocations, ConstantRange::multiply was 6.5% of ‘opt -O2’ time on this use case, and after a series of patches to reduce its allocations from 26m to 16m, it drops to about 2.5% of compile time.
> 
> I’ve only covered the case where the LHS is an APInt&& and RHS is a uint64_t.  I could add in all the possible cases, i.e.:
> - LHS is APInt&&, RHS is APInt&
> - LHS is APInt&, RHS is APInt&&
> - LHS is APInt&&, RHS is APInt&&
> 
> I’m happy to do this, but it may eventually become unwieldy.
> 
> What do you think of this particular patch, and then what do you think about going forwards whether its a good idea to cover the other cases with r-value refs?
> 
> Cheers,
> Pete
> 
> <apint.diff>_______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits