[PATCH] Use Rvalue refs in APInt

[Pete Cooper via llvm-commits]

> On May 31, 2016, at 6:29 PM, Matthias Braun <mbraun at apple.com> wrote:
> 
> 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.
Yeah, i’ve been wondering about a BumpPtrAllocator, or even just a greater amount of inline storage.  An APInt is effectively a SmallVector<uint64_t, 1> in some sense but could have 2 or even more elements inline if it made sense.  

Given that the majority of long-lived APInt’s are uniqued inside ConstantInt, we may not even see much of a peak memory increase by doing this.  But its just a theory right now, and may be complicated to even try it.

Cheers,
Pete
> 
> - 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
>