From: dontmailme AT iname DOT com (Steamer) Newsgroups: comp.os.msdos.djgpp Subject: Re: inefficiency of GCC output code & -O problem Date: Wed, 19 Apr 2000 12:17:10 GMT Organization: always disorganized Lines: 61 Message-ID: <38fda3ac.16306923@news.freeserve.net> References: NNTP-Posting-Host: modem-172.missouri.dialup.pol.co.uk X-Trace: newsg1.svr.pol.co.uk 956146632 13647 62.137.76.172 (19 Apr 2000 12:17:12 GMT) NNTP-Posting-Date: 19 Apr 2000 12:17:12 GMT X-Complaints-To: abuse AT theplanet DOT net X-Newsreader: Forte Free Agent 1.11/32.235 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Eli Zaretskii wrote: >I suggest to report this to the GCC maintainers. I intend doing so once I've found out where and how I'm supposed to report GCC bugs, and have checked the list of known bugs (wherever that may be). >The GCC docs does >not mention this incompatibility, so it's either a documentation bug, >or a GCC bug, if it is supposed to work. > >I suspect the former. In general, GCC maintainers will tell you that >if you use switches that change the ABI, you should expect certain >things to break. For example, there are some switches of this kind >that break debugging. Yes, it's probably not reasonable to expect it to work. But I think it should at least simply ignore the regparm attribute when -pg is used. (That this would slightly distort the profile is a minor issue, since the profiling code itself distorts the profile.) >> Of course, it's possible to work around it with something like >> >> #if defined __DJGPP__ && !defined PROFILING >> #define REGPARM(n) __attribute__ ((regparm(n))) >> #else >> #define REGPARM(n) >> #endif >> >> but then it's necessary to remember -DPROFILING in addition to -pg. > >If you are willing to live without regparm when profiling and profile >code that doesn't use regparm, then why is this an issue? You could >simply compile only some functions with -pg and leave those which use >regparm without profiling instrumentation. Since regparm will >ususally be limited to a well-defined small subset of your program, it >shouldn't be too hard to decide how to compile each module. I prefer the -DPROFILING solution because then I still get the information about how many times the function is called (which tends not to be obvious in my programs). >I thought the issue was that you *wanted* to profile code _while_ it >was using regparm (for obvious reasons). Well, I would obviously prefer this (although the overhead of profiling would probably mask any gain due to use of regparm anyway). But I'm used to not being able to profile my actual code, because my programs usually work faster with -fomit-frame-pointer, which has to be left off during profiling. The issue was really that -pg doesn't even produce a warning if used with regparm functions, it simply produces incorrect code which will either cause a crash or (worse) cause the program to run completely differently than it would normally, producing a meaningless profile. I've found that using regparm for selected functions does produce a measurable (albeit small) speed-up, but this has to be measured by means other than profiling. S.