Rafael Avila de Espindola
2011-Feb-25 19:38 UTC
[LLVMdev] [MC] Removing relaxation control
>> 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. Cheers, Rafael
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
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
>
On Sat, Feb 26, 2011 at 11:51:48AM -0800, Chris Lattner wrote:> 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.I was looking into this and there is a problem with -save-temps. The attached patch works and does the right thing, if that option is not used. With -save-temps, the problem is that at that point, it is impossible to distingiush between C input and (preprocessed) assembler files. For the former, POLA would dictate that -mrelax-all is used for -O0, for the latter it is definitely not desirable. I can't find a clean way to do without making a mess of the action construction. Joerg -------------- next part -------------- A non-text attachment was scrubbed... Name: Tools.cpp.diff Type: text/x-diff Size: 816 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110304/8824c848/attachment.diff>