On Fri, Jan 17, 2014 at 9:46 PM, Jed Brown <[email protected]> wrote:
> Barry Smith <[email protected]> writes: > > > Yes, What if they just set a single flag having nothing to do with > > optimization. This will turn off PETSc’s attempt to provide any > > kind of optimization flag (even with —with-debugging=0). I think > > this is bad. * > > Is it really that bad? Other packages usually don't try to do anything > smart and I think there is a very real cost to second-guessing the user. > Worse, the user has to wait minutes for configure to complete before > reading the printout carefully to learn what PETSc decided to use. > > I think we still want warning flags because users are unlikely to guess > decent ones. And -fPIC needs to be automatic based on shared libs. > > >>> Could we do the following? > >>> > >>> Look through any provided CFLAGS (FFLAGS, CXXFLAGS) if we detect > >>> something that looks like optimization then act as if COPTFLAGS was > >>> set and do not set our own optimization default flag? We can also > >>> keep support for the COPTFLAGS stuff > >>> > >>> We can look for -O%d , are there other things to look for? This > seems easy enough to add. > >> > >> -ftree-vectorize, -fast, -qhot -qsimd=auto > > > > So if they pass -fast then we simply don’t set any optimization flags > ourself? We could do that. > > My point was that there are *lots* of optimization flags, with new ones > every release from every vendor. We could test for a few, but can never > be comprehensive. Do we want to be in this business? > I am a fan of our current organization, which is the right mix of flexibility and performance. I don't think we can do much better, since we are stuck with the crap command line interface to compilers. I hate compilers. Matt -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener
