From: Olly B. <ol...@su...> - 2006-03-13 23:04:35
|
On Sun, Mar 05, 2006 at 08:50:34PM -0700, Marcelo Matus wrote: > Olly Betts wrote: > >The only documentation for it seems to be in CHANGES and as a result > >it's not so easy to get a coherent overview, > > swig -help also gives you a descriptions of all the available flags as > well as which one are the turned on by -O. Aha, that's a help (hmm, I just noticed that "swig -python --help" doesn't do the same as "swig -python -help"...) But as a user, it's less than ideal that a number of features seem to have been documented only in the CHANGES file, not the manual. In some cases the relevant section can be pretty much read as-is, but in others a "timeline" of changes needs condensing to describe the final state. I'm not meaning to pick on Marcelo's recent work here. I've noticed this before with some other features and it's working against reaching SWIG 2.0 if one of the targets is to make sure that the documentation is complete, as most recently suggested here: http://thread.gmane.org/gmane.comp.programming.swig.devel/15884 > The compiler will tell you if there is a problem with an option and a > given python version, for example, if you use just: > > swig -O ... > > with Python 2.1, you will get the following messages at compilation time: > > autodoc_wrap.cxx:2468:3: #error "This python version requires to use > swig with the '-nomodern' option" > autodoc_wrap.cxx:2471:3: #error "This python version requires to use > swig with the '-nofastunpack' option" OK, I've been trying out -O and friends. It appears that -dirvtable is incompatible with Python 2.1 because it generates (or at least can generate) calls to PyObject_Call which Python 2.1 doesn't have. But there's no #error for that one. In the case of -dirvtable at least, it should be possible to generate one SWIG wrapper file which works on both Python versions, since both versions of the code are present - it just needs a preprocessor check to only define SWIG_PYTHON_DIRECTOR_VTABLE for Python 2.2 and later. Otherwise it seems to work fine for me in testing so far. > then you just compose the command > > swig -O -nomodern -nofastunpack ... That requires me to recheck on every SWIG upgrade if there are any new options in -O and if so whether they work with Python 2.1, etc and if not to expand the list of "-noXXX" options. It'd be nicer to be able to specify a "minimum python version" for -O to use to decide which options it enables, which would help prevent this problem. Or perhaps best of all would be to generate both variants of the code and pick which to use at compile time based on the Python version being used, but I can see that might be hard to implement. Hmm, but that gives me a neat idea - in my own build system I can generate suitable wrapper files for "Python 2.1" and "Python 2.2 and later" as I currently do, and then merge them using GNU diff's "--ifdef" option so I can actually ship a single wrapper file which can automatically build with whatever python version is available. > >I don't want to use "-O" only to find a new SWIG release adds to > >"-O" in a way which breaks my wrappers. I realise that there's probably > >a small risk, as really safe new optimisations would presumably just > >default to on, but I guess I'm trying to gauge what the possible scope > >of "-O" is. > > if you find one of the options to conflict with your code, you always > can disable the culprit, for example > > swig -O -nofastproxy I can, but if I don't detect the problem before making a release this introduces a regression in my software as far as my users are concerned. > in the same way with -O1,O2,O3, you need to check if nothing gets broken > when you use -O. But if "gcc -O3" or "g++ -03" breaks my software, that means either GCC is buggy, or more likely that my software violates the ISO C or ISO C++ standard. There's no "ISO SWIG standard" that I can code my ".i" file to. There's "what's documented in the manual", but that's incomplete in places. > >Also, are most of the optimisations Python-only? It looks like -fvirtual > >applies to other languages, but the others seem to be Python-specific. > > well, -fastdispatch and -fvirtual are 'global', the rest are mainly > python specific ones. OK, time to test -O with the other languages! Cheers, Olly |