Date: Tue, 17 Feb 2004 15:47:37 -0500 From: Chuck Swiger <cswiger@mac.com> To: Paul Seniura <pdseniura@techie.com> Cc: freebsd-questions@freebsd.org Subject: Re: need help on CFLAGS in /etc/make.conf please Message-ID: <40327DE9.1030303@mac.com> In-Reply-To: <20040217183545.E65B95C22@techpc04.okladot.state.ok.us> References: <20040213001703.616C75C3B@techpc04.okladot.state.ok.us> <20040213011324.GA55948@xor.obsecurity.org> <20040213035608.3AA11A38EA@scifi.homeip.net> <402D070D.90506@mac.com> <20040217183545.E65B95C22@techpc04.okladot.state.ok.us>
next in thread | previous in thread | raw e-mail | index | archive | help
Paul Seniura wrote:
> Hi Chuck,
Hi, Paul--
> The delay in my response here was due to pest control in our building
> and the three-day weekend (I have no li'l-endians at home ;) .
No problem...and a good job of solving the endian-debate. :-)
>> Paul Seniura wrote:
>>> My question for this discussion is specifically how to prevent
>>> overriding a port's own setting for that parm, and to provide a
>>> default setting -O[1] when the port does not set it at all?
>>
>> Well-behaved ports respect CFLAGS, meaning that you can define that variable
>> in /etc/make.conf (or on the command line when you invoke make), and the port
>> should use that value when building the software.
>
> Sorry to say, I don't think you're getting my gist here. ;)
That may be so; but I can only answer your question as it was asked.
> I want a default setting -O "iff"=="if and only if" the original does not
> provide it. That's what "default setting" means. ;)
If the port uses "CFLAGS ?=" or uses that value via implicit rules, you will
get the behavior you've asked for by not setting CFLAGS at all: ie, the port
will use whatever CFLAGS setting it has as the default unless another value is
specified elsewhere.
If the port uses "CFLAGS =", the port Makefile or possibly a patch in the
files subdirectory ought to override this to pay heed to the system-wide
settings. In this case, you will have to modify that mechanism for each
relevant port yourself.
> Also, I do not want to override the original's optimization settings either
> if there was one provided -- my "default setting" isn't used in this case.
You're basicly re-iterating the position that the author of the software
should be the ones to set compiler flags. That's a reasonable position, but
it misses a vital consideration:
[ ...a snippet from a related thread, where an author of a port I maintain
disagreed about the port overriding CFLAGS... ]
] As for ?= in the same file. I don't find conditional assignment of [at
] least] CFLAGS/CXXFLAGS appropriate. Well, as it is right now, "complain"
] is probably not relevant, as I don't use any "extra ordinary" options
] (-no-exception is uses solely to minimize executables' sizes), but
] generally speaking compiler flags should be my choice, not yours so to
] say. At least on some extent, e.g. CFLAGS +=. Don't you think?
The reasoning for that change is much the same as above, actually. I'm a
network manager, not a developer. So long as it's documented and reasonable,
and it works, I'm not going to change it.
The original patch I submitted didn't change those, either. Someone
(fjoe/Matt Khon?, anyway a FreeBSD committer) pointed me towards:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-restrictions.html#AEN1993
http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/porting-dads.html
...such as "15.13 Respect both CC and CXX
<http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/dads-cc.html>"
and "15.14 Respect CFLAGS
<http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/dads-cflags.html>".
...before the port was accepted and committed. It's normal for FreeBSD users
to set CFLAGS in /etc/make.conf for the entire system, and ports are marked
"broken" (meaning not included with CD distributions and not available in
pre-compiled form on ftp sites) if NO_PACKAGE is defined.
That being said, to address your point with regard to ownership more directly,
the choice of compiler flags should be the choice of the end-user compiling
the software, and this change was made to facilitate that.
(s/made/required, if you please.)
=====
> See what I mean?
Certainly. Your position is reasonable.
However, the decision to facilitate the end-user deciding which optimization
levels (aka default CFLAGS) are to be used is a policy decision by the ports
system, but one which I strongly agree with.
> And as far as i386 is concerned, it is looking like -O2 is the "maximum"
> that should be attempted. Other platforms, e.g. -march=7450 I use at home,
> can go -O5 without problems. At any rate, I certainly want to cut-down
> anything like what Kris mentions e.g. -O999!
It's entirely likely that -O3, -O5, and -O999 will all behave exactly the
same. Have you benchmarked any differences in performance?
You might find it interesting to review a thread from July of last year titled
"buggy optimization levels", in which I wrote: /usr/src/contrib/gcc/toplev.c
is clear enough which specific optimizations are involved at the different
number levels:
if (optimize >= 1)
{
flag_defer_pop = 1;
flag_thread_jumps = 1;
#ifdef DELAY_SLOTS
flag_delayed_branch = 1;
#endif
#ifdef CAN_DEBUG_WITHOUT_FP
flag_omit_frame_pointer = 1;
#endif
}
if (optimize >= 2)
{
flag_cse_follow_jumps = 1;
flag_cse_skip_blocks = 1;
flag_gcse = 1;
flag_expensive_optimizations = 1;
flag_strength_reduce = 1;
flag_rerun_cse_after_loop = 1;
flag_rerun_loop_opt = 1;
flag_caller_saves = 1;
flag_force_mem = 1;
#ifdef INSN_SCHEDULING
flag_schedule_insns = 1;
flag_schedule_insns_after_reload = 1;
#endif
flag_regmove = 1;
}
if (optimize >= 3)
{
flag_inline_functions = 1;
}
This was for gcc-2.95; in gcc-3.4 this code was moved to a file called opts.c,
but -O4, -O5, and -On for any n >=3, all do the same thing. Really!
[ ... ]
> A msg from Richard Coleman, taken together with the GCC 3.x Known Bugs
> site, is leading me to believe any bugs solely due to higher -O levels need
> to be fixed by the author(s) of the software.
Heh. With regard to optimization, page 586 of _Compilers: Principles,
Techniques, and Tools_ states:
]First, a transformation must preserve the meaning of programs. That is, an
]"optimization" must not change the output produced by a program for a given
]input, or cause an error, such as a division by zero, that was not present in
]the original program. The influence of this criterion prevades this chapter;
]at all times we take the "safe" approach of missing an opportunity to apply a
]transformation rather than risk changing what the program does.
[ ... ]
> You're changing what the author sets-up before any hack-job I invent will
> even see it. Why? If I interpret what Kris said correctly, he wants you
> to think GCC 3.x is the source of the bugs at -O2+.
You're not interpreting Kris' position correctly.
I believe that Kris disavows setting higher optimization levels because it is
extremely difficult to track down the bugs which result (most particularly in
the kernel, which must do all sorts of pointer-aliasing games) and thus the
cost/benefit ratio of higher optimizations isn't worth his time.
[ ... ]
> I reiterate the notion of other platforms working fine with optimizations
> and FBSD is slowing down because IMHO of some age-old assumptions about GCC
> itself. As a specific example: If GCC 3.3.3 generates really fast code
> on a Linux/i386 app *and* it's proven to work well, then FBSD/i386's code
> should fly just as fast at the same level with no problem. Oh but y'all
> are hacking the guts out of the optimization settings coming from the
> author, so FBSD/i386 will never see the same end-results here.
Paul, you really ought to benchmark what the compiler actually does between
-O2 and -Onnn: often, there is zero difference in performance.
It would be unusual for there to be more than a factor-of-two difference in
performance between unoptimized code and -O (aka -O1); -O2 might buy you
another 10-20%, and -O3, -O4, or higher 5% or less. YMMV.
--
-Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40327DE9.1030303>