[LLVMdev] [MC] Removing relaxation control

Rafael Ávila de Espíndola rafael.espindola at gmail.com
Thu Feb 24 20:48:41 PST 2011


> E.g. -mrelax-all is either harmful or not improving enough to give a
> measurable improvement.
> 
> Can someone else try to reproduce this?

I can. I tried these builds on tmpfs so as to give -mno-relax-all an
smaller advantaged for less IO:

--enable-optimized --with-optimize-option=-O0
real	3m38.568s
user	24m15.097s
sys	1m33.550s

clang is 69661804 bytes

 --enable-optimized --with-optimize-option="-O0 -mno-relax-all"

real	3m38.902s
user	24m18.423s
sys	1m34.074s

clang is 68805740 bytes

and on disk

 --enable-optimized --with-optimize-option="-O0 -g"

real	4m59.298s
user	29m22.683s
sys	2m24.325

clang is 686194963 bytes

 --enable-optimized --with-optimize-option="-O0 -g -mno-relax-all"
real	4m58.735s
user	29m34.127s
sys	2m25.734s

clang is 685305227 bytes

> I've also did some testing with a worst case assembler file doing lots
> of jumps that can all be relaxed. In that case, -mno-relax-all was 25%.
> If the above observation can be confirmed, I believe there is no good
> reason to keep -mrelax-all.

To the best of my knowledge relaxation is more expensive on ELF than on
Mach-O since there are less opportunities on Mach-O. Given that, I think
it is save to conclude that we can drop relax-all (and that I should
figure out what is going on with the size of debug binaries on ELF).

> Joerg

Cheers,
Rafael



More information about the llvm-dev mailing list