[LLVMdev] [MC] Removing relaxation control
Daniel Dunbar
daniel at zuster.org
Sat Feb 26 15:00:17 PST 2011
Yeah, I would rather not turn it off.
Note that in the context of *just* the assembler time, it has a pretty
large impact:
--
ddunbar at ozzy:MC-403.gcc$ runN 10
/Users/ddunbar/llvm.obj.64/Release/bin/clang -m32 -c -O0 i386.normal.s
name avg min med max SD total
user 0.1753 0.1729 0.1752 0.1768 0.0010 1.7533
sys 0.0221 0.0247 0.0222 0.0225 0.0011 0.2210
wall 0.2580 0.3186 0.2560 0.2593 0.0220 2.5800
ddunbar at ozzy:MC-403.gcc$ runN 10
/Users/ddunbar/llvm.obj.64/Release/bin/clang -m32 -c -O0 i386.normal.s
-mno-relax-all
name avg min med max SD total
user 0.1883 0.1853 0.1878 0.1927 0.0023 1.8831
sys 0.0283 0.0287 0.0266 0.0262 0.0016 0.2828
wall 0.3247 0.2869 0.3326 0.3295 0.0463 3.2474
ddunbar at ozzy:MC-403.gcc$
--
That's 10% faster, which is a big deal.
Overall, of course, the assembler time isn't that much of the total
compile time, so the overall impact isn't that large, but I like
following the model of trying to keep individual components as fast as
possible.
Note the impact that -mrelax-all has on the assembler stats:
--
ddunbar at ozzy:MC-403.gcc$ clang -m32 -c -w -DSPEC_CPU -DSPEC_CPU_MACOSX
-I. -O0 i386.c -mllvm -stats 2>&1 | grep assembler
1 assembler - Number of assembler layout and relaxation steps
1182 assembler - Number of emitted assembler fragments
279600 assembler - Number of emitted object file bytes
9090 assembler - Number of evaluated fixups
1201 assembler - Number of fragment layouts
ddunbar at ozzy:MC-403.gcc$ clang -m32 -c -w -DSPEC_CPU -DSPEC_CPU_MACOSX
-I. -O0 i386.c -mllvm -stats -mno-relax-all 2>&1 | grep assembler
2 assembler - Number of assembler layout and relaxation steps
9648 assembler - Number of emitted assembler fragments
267264 assembler - Number of emitted object file bytes
23872 assembler - Number of evaluated fixups
24604 assembler - Number of fragment layouts
1061 assembler - Number of relaxed instructions
ddunbar at ozzy:MC-403.gcc$
--
We get about 8x the number of fragments and 20x the number of fragment layouts.
- Daniel
On Sat, Feb 26, 2011 at 11:51 AM, Chris Lattner <clattner at apple.com> wrote:
>
> On Feb 25, 2011, at 11:38 AM, Rafael Avila de Espindola wrote:
>
>>>> Can someone else try to reproduce this?
>>
>> I tried gcc.c from
>> http://people.csail.mit.edu/smcc/projects/single-file-programs/ and the
>> difference is a bit more noticeable:
>>
>> -O0 -mno-relax-all
>>
>> real 0m13.182s
>> user 0m12.690s
>> sys 0m0.450s
>>
>> -O0
>>
>> gcc.o is 10932968 bytes.
>>
>> real 0m12.969s
>> user 0m12.520s
>> sys 0m0.410s
>>
>> gcc.o is 11410552 bytes
>>
>> IMHO it would still be reasonable to switch to no-relax-all, but I am
>> probably not the best one to make the call.
>
> That looks like a 1.5% speedup in realtime and 10% speedup in system time (though I'm not sure I believe that). I think it should stay on for -O0 for C files. Turning it off at -O0 for .s files makes perfect sense to me though.
>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
More information about the llvm-dev
mailing list