llvm dev - Nov 2009 - [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

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

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