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>