Re: Preparsing sprintf format strings
Kaveh R. GHAZI wrote:
> On Mon, 8 Oct 2007, Heikki Linnakangas wrote:
>
>> sprintf(dest, "%d", arg1); -> a new function that does the same thing,
>> but without the overhead of parsing the format string. Like itoa on some
>> platforms. We could inline it as well. That would allow further
>> optimizations, if for example the compiler knows that arg1 is within a
>> certain range (do we do that kind of optimizations?)
>>
>> sprintf(dest, "constant%...", args...) -> memcpy(dest, "constant", 8);
>> sprintf(dest+8, "%...", args...);
>>
>> sprintf(dest, "%dconstant%...", args1, args...) -> sprintf(dest, "%d",
>> args1); memcpy(dest+X, "constant", 8); sprintf(dest+XX, "%...", args...);
>
> In my experience changing one library call into several creates code bloat
> more often than it improves runtime speed. I think you should only do
> this when profile feedback indicates you've hit a heavily used spot in
> your code.
Note that the memcpy's will be simplified further. Point taken, though.
I think the tradeoff is similar to -finline-functions and
-funswitch-loops, that we do with -O3.
> E.g. should we turn printf("ab") into putchar('a'); putchar('b'); ?
> I'd say not, unless that code was a hot spot.
>
> One simplification I don't believe we do yet, that should always be a win,
> is turning: sprintf (foo, "%c", bar); into:*foo = bar;
Don't forget the null terminator ;-). Yeah, that seems always worth
doing. In printf, we already turn that into putchar.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Re: Preparsing sprintf format strings
Joe Buck wrote:
> If your program has one or two dominant sprintf calls (as in the example
> that motivated this exercise), it pays off. But for a large program with
> thousands of {,s,f}printf calls, this kind of code size expansion could
> easily hurt instead of help. Without some data showing a payoff for
> large programs, I don't think that this kind of exercise would pay off.
Well, I bumped into this by profiling PostgreSQL, which uses sprintf for
almost all output formatting, like sending results to the client. I've
seen sprintf taking a significant amount of CPU time in oprofile output
in two different test cases. One is exporting a table with timestamp
columns, which uses a format string like "%04d-%02d-%02d %02d:%02d".
Another was loading a large number of records with INSERTs. After each
INSERT statement, a result code is sent to the client, using "INSERT %u
%u". I don't have the numbers at hand, but I can get them if you want.
That's for the large program I'm familiar with. Apparently it plays a
role in Linux as well since they've spent effort on a more performant
implementation. I suspect that many programs have already replaced the
most speed-sensitive sprintf calls with customized code, at the cost of
readability.
> And then consider that any solution has to work correctly with arbitrary
> locales; this could be done with your proposed new library function,
> but it's starting to turn into a rather big project for questionable gain.
The only features in the printf-family of functions that depends on the
locale are the conversion with thousand grouping ("%'d"), and glibc
extension of using locale's alternative output digits ("%Id"). We can
easily just fall back to glibc sprintf in those cases. I was only
thinking of implementing only the most commonly used formats anyway,
initially at least.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Problem with optimization passes management
There is a conflict between the command line switches that turn off individual optimization steps and their preconditions. Compiling a "hello world" with the following options: -O1 -fno-tree-salias causes gcc to fail with an internal consistency check. Pass return_slot has PROP_alias in its preconditions but alias information is not generated due to the second option. Regards, Wolfgang --- Dr. Wolfgang Gellerich IBM Deutschland Entwicklung GmbH Schönaicher Strasse 220 71032 Böblingen, Germany Tel. +49 / 7031 / 162598 [EMAIL PROTECTED] === IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Johann Weihen Geschäftsführung: Herbert Kircher Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294
Re: Problem with optimization passes management
On 10/10/07, Wolfgang Gellerich <[EMAIL PROTECTED]> wrote: > > There is a conflict between the command line switches that turn off individual > optimization steps and their preconditions. Compiling a "hello world" with the > following options: This one issue is know, it was reported as PR 33092. Thanks, Andrew Pinski
gcc mirror
Hi Gcc Webmaster, I estabilished an http mirror via rsync, updated four times a day with a cron job, located in Utah (US), available at the URL "http://gcc.bigsearcher.com/";, from my server bigsearcher.com; Please add this mirror to the list of available mirror location. Best regards, Andrea
Re: Problem with optimization passes management
> On 10/10/07, Wolfgang Gellerich <[EMAIL PROTECTED]> wrote: > > > > There is a conflict between the command line switches that turn > off individual > > optimization steps and their preconditions. Compiling a "hello > world" with the > > following options: > > This one issue is know, it was reported as PR 33092. > Sorry for the duplicate! Regards, Wolfgang
Re: Preparsing sprintf format strings
On Wed, Oct 10, 2007 at 12:12:25AM -0400, Kaveh R. GHAZI wrote: > One simplification I don't believe we do yet, that should always be a win, > is turning: sprintf (foo, "%c", bar); into:*foo = bar; You need the null terminator: foo[0] = bar; foo[1] = 0; But these things are rarely going to be a huge win, and I get the impression that competing compiler developers only do them when they help with standard benchmarks.
Re: Inconsistent use of __GTHREAD_HAS_COND
Jason Merrill wrote: fafa wrote: I tried to build gcc from the latest snapshot (gcc-4.3-20071005), but I undefined the symbol "__GTHREAD_HAS_COND" which is desribed in libstdc++-v3\ChangeLog as follows: ... [!__GTHREAD_HAS_COND] Fall back to the old code, which deadlocks. ... But libstdc++-v3\libsupc++\guard.cc uses the class __guard from libstdc++-v3\include\ext\concurrence.h which depends on the symbol __GTHREAD_HAS_COND and is undefined now. Hmm? __guard is a typedef in cxxabi-tweaks.h and doesn't depend on __GTHREAD_HAS_COND. Jason Sorry, my bad; i meant __cond instead of __guard ! But libstdc++-v3\libsupc++\guard.cc uses the class __cond from libstdc++-v3\include\ext\concurrence.h which depends on the symbol __GTHREAD_HAS_COND and is undefined now. in the static variable static __gnu_cxx::__cond* static_cond; in line 68 of guard.cc. So class __cond is unknown when I link with the above built version. Maett
Re: Inconsistent use of __GTHREAD_HAS_COND
FYI this was libstdc++/33682, and was fixed with: http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00415.html Which was checked in yesterday. Please update your sources and try again. best, -benjamin
University coursework & GCC
Hello, I am currently looking for a topic for graduation thesis. I would like it to be in the area of GCC code generation enhancements, and my current best choice is providing predication support in selective scheduling. If you have anything to suggest, I will be very glad to hear; or maybe your answers will provide helpful directions for other students who want a GCC-related term/graduation project. Thanks. -- Alexander Monakov
MIPS testsuite failures...
I am pleased that the current trunk is looking to be in very good shape for the mipsel-linux target: http://gcc.gnu.org/ml/gcc-testresults/2007-10/msg00397.html The gcc.c-torture/execute/loop-2[fg].c FAILures are due to kernel bugs. gcc.c-torture/execute/mayalias-[23].c FAIL on x86_64-pc-linux so I am not too concerned about them. There are two GCC tests for which I cannot explain the failures: FAIL: gcc.dg/memcpy-1.c scan-tree-dump-times nasty_local 0 FAIL: gcc.target/mips/dse-1.c scan-assembler-not \\tlw\\t I wonder if anyone can shed light on these failures. It would be nice to fix the MIPS target enough for 4.3 that it would be as good (from a testsuite point of view) as x86_64. David Daney
Re: MIPS testsuite failures...
David Daney <[EMAIL PROTECTED]> writes: > There are two GCC tests for which I cannot explain the failures: > > FAIL: gcc.dg/memcpy-1.c scan-tree-dump-times nasty_local 0 This is on my list of things to look at. It seems to fail on 32-bit MIPS targets but not 64-bit ones. > FAIL: gcc.target/mips/dse-1.c scan-assembler-not \\tlw\\t This is fixed by: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01844.html (which FWIW I've now pinged twice: http://gcc.gnu.org/ml/gcc-patches/2007-09/msg02110.html http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00370.html ) Richard
Successfully built and installed gcc 4.2.2
$ ./config.guess i686-pc-linux-gnu $gcc -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/usr --enable-shared --enable-threads --enable-languages=c,c++,fortran,java,objc,obj-c++,treelang --enable-__cxa_atexit Thread model: posix gcc version 4.2.2 Linux distribution: Slackware 12.0 (but for compiling I used gcc 4.2.1 built by myself) $ uname -a Linux darkenergy 2.6.22.9 #1 Wed Sep 26 21:53:52 CEST 2007 i686 AMD Sempron(tm) Processor 2800+ AuthenticAMD GNU/Linux Glibc version: 2.5 Thank you very much for your excellent and precious work! Have a nice day! Gabriele Inghirami
Re: Preparsing sprintf format strings
On Wed, 10 Oct 2007, Joe Buck wrote: > On Wed, Oct 10, 2007 at 12:12:25AM -0400, Kaveh R. GHAZI wrote: > > One simplification I don't believe we do yet, that should always be a win, > > is turning: sprintf (foo, "%c", bar); into:*foo = bar; > > You need the null terminator: foo[0] = bar; foo[1] = 0; Yeah, my oops. Two 1-byte stores is still faster (and smaller!) than a sprintf function call with three arguments. > But these things are rarely going to be a huge win, and I get > the impression that competing compiler developers only do them > when they help with standard benchmarks. Their loss. I agree with avoiding these micro opts when they cause bloat. But when you win in both size and speed, IMHO we should do it. --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
Re: Scheduling problem - A more detailed explain
ÎâêØ wrote: Well... Is there anything I miss or forget to do ? Someone needs to step through code in a debugger and try to figure out what is going wrong. I made an initial attempt at that. I hacked gcc a little to try to force a failure with a contrived testcase. The first thing I noticed is that I pointed you at the wrong bit of code. The rws_access_reg code is used for placing stop bits, which is not the problem here. The problem here is in the scheduler. Unfortunately, this leads to a second problem. How this works in the scheduler depends on what gcc sources you are using. There is the pre-dataflow merge code and the post-dataflow merge code. I don't know which one you are using. From earlier comments, I'm guessing that you are using some snapshot from mid to early summer. It would be helpful to know exactly what sources you are starting from. Worst case, I might also need your gcc patches, if I can't find a way to trigger the failure on my own. The scheduler dep code is in sched-deps.c. Try looking at sched_analyze_insn. As before, it does use hard_regno_nregs so in theory it should be working. Do we know for sure that the scheduler is failing here? Have you looked at -da RTL dumps to verify which pass is performing the incorrect optimization? Currently, gcc only emits these pr reg group save/restores in the prologue and epilogue, and we have scheduling barriers after/before the prologue/epilogue, so it is possible that there is a latent problem here which has gone unnoticed simply because it is impossible to reproduce with unmodified FSF gcc sources. -- Jim Wilson, GNU Tools Support, http://www.specifix.com
Re: Preparsing sprintf format strings
On Wed, Oct 10, 2007 at 04:22:45PM -0400, Kaveh R. GHAZI wrote: > > But these things are rarely going to be a huge win, and I get > > the impression that competing compiler developers only do them > > when they help with standard benchmarks. > > Their loss. I agree with avoiding these micro opts when they cause bloat. > But when you win in both size and speed, IMHO we should do it. Certainly. I think anything that turns one call into one cheaper call will always win, and we already do a bit of that (as you say, this wins for both size and speed).
Re: Scheduling problem - A more detailed explain
2007/10/11, Jim Wilson <[EMAIL PROTECTED]>: Thanks for you helpful hints ! And I am sorry for such a late reply. I have figured out this problem yesterday :-). > Do we know for sure that the scheduler is failing here? Have you looked > at -da RTL dumps to verify which pass is performing the incorrect > optimization? > I use the method you mentioned above to find the problem, the scheduling code that GCC used is correct, but there are some errors with the order of my instrumentation INSN list. So... > Currently, gcc only emits these pr reg group save/restores in the > prologue and epilogue, and we have scheduling barriers after/before the > prologue/epilogue, so it is possible that there is a latent problem here > which has gone unnoticed simply because it is impossible to reproduce > with unmodified FSF gcc sources. Previously, I also doubt that it is a latent problem, however, I read the code you mentioned and find it is correct with pr reg group save/restore, and finally find it is due to my carelessness in the instrumentation code; so, sorry for that :-).
