Pekka Jääskeläinen
2009-Nov-22 22:08 UTC
[LLVMdev] [PATCH] increase the max number of physical registers
Hi, Chris Lattner wrote:> This is fine to me in principle, but please make sure this doesn't > impact compile time or memory usage of llc somehow.OK. Any recommended way to do this? Is there some nice way to benchmark speed + memory consumption of llc in LLVM testing infra at the moment or should I just use 'top' to the inspect memory consumption and 'time' for speed measurements with a code generation from a big bitcode? -- Pekka Jääskeläinen Department of Computer Systems Tampere University of Technology, Finland http://tce.cs.tut.fi
Chris Lattner
2009-Nov-23 18:35 UTC
[LLVMdev] [PATCH] increase the max number of physical registers
On Nov 22, 2009, at 2:08 PM, Pekka Jääskeläinen wrote:> Hi, > > Chris Lattner wrote: >> This is fine to me in principle, but please make sure this doesn't >> impact compile time or memory usage of llc somehow. > > OK. Any recommended way to do this? Is there some nice way to benchmark > speed + memory consumption of llc in LLVM testing infra at the > moment or should I just use 'top' to the inspect memory consumption > and 'time' for speed measurements with a code generation from > a big bitcode?Please compare a release-asserts (make ENABLE_OPTIMIZED=1 DISABLE_ASSERTIONS=1) builds with and without your patch. Just run 'llc' on a collection of large bc files (e.g. kimwitu++ from the testsuite, some SPEC2K6 programs if you have access to it, etc) and compare them. Thanks! -Chris
Pekka Jääskeläinen
2009-Nov-24 18:07 UTC
[LLVMdev] [PATCH] increase the max number of physical registers
Chris Lattner wrote:> Please compare a release-asserts (make ENABLE_OPTIMIZED=1 > DISABLE_ASSERTIONS=1) builds with and without your patch. Just run > 'llc' on a collection of large bc files (e.g. kimwitu++ from the > testsuite, some SPEC2K6 programs if you have access to it, etc) and > compare them.OK. I compared the speed + memory consumption for a llc of a 8M bitcode (AES encryption of 64 blocks, fully unrolled to a single BB). No difference. Both had about 700M peak virt memory consumption and it took about 45mins for 10 rounds. More elaborate results: Executed: time for i in $(seq 10); do echo $i; llc aes.bc -f -o aes.o; done; Peak memory consumption monitored with while true; do pmap $(pgrep llc) | tail -1; sleep 1; done; The smallest and largest max values (of the 10 runs) were picked from the output. Without the patch: mem 690960K ... 715476K real 46m53.966s user 46m32.299s With the patch: mem 691096K ... 715608K real 46m10.101s user 45m56.944s -- Pekka