Enable -oh compilation switch

[javiergutierrezchamorro]

Acording to the documentation, the -oh flag (enable repeated optimizations (longer compiles)), will generate a better code, at the cost of extra compile times. Most of the time, OpenWatcom is using /oax or /oaxt, and maybe adding /oh will be worth, at least in some parts like the clib. What do you think?

[javiergutierrezchamorro]

OK, pull request created with the addition of -oh: https://github.com/open-watcom/open-watcom-v2/pull/90

[jmalak]

I don't think it is good idea. -oh option causes that CG optimization will be several times longer then with existing setup. Please, give me some results from checking code improvement if any and comparision time which is necessary for building some project with this setup against existing setup.

[javiergutierrezchamorro]

In my development environment, it increased compilation time on only 10%. Here are the results:

• Clean build without -oh: 61 min
• Clean build with -oh: 67 min

I think that 6 minutes in comparisson with one hour, is not a big deal if we consider possible performance improvements in runtime performance.

What do you think?

[jmalak]

It is overal time with a few projects compiled with -oh? I am interested in one bigger project difference. What about generated code, do you have some comparision? what is gain? -oh option "could" improve code, but is it realy true? -oh option is not tested by any regression test that this option could be un-reliable, without serious testing we can not use it

[javiergutierrezchamorro]

This was the time for a full build by adding -oh to bootstrap, clib, f77lib, mathlib and some Windows tools as in the pull request.

On the generated code, there is no messurable improvement, but some EXE sizes differences, usually a bit smaller, and some times a bit larger.

There is almost no documentation about it, but it seems that optimizations will be applied over different passes if needed, which have no reason to break generated code.

Also being the bootstrap itself compiled with /oh, did not cause any faults on the code generation, and the toolchain worked fine, so I do not have any reason to consider it risky.

I would say that the improvement is not so high, but also the cost is neither.

In my opinion it makes sense to apply. At lest on the libraries, because the benefits will be propagated to the programs that link them. Either OpenWatcom tools, or user's compiled programs.

If the concern is regarding this 10% or additional compile time, maybe one approach would be adding a parameter on build or a new target on builder that could build everything for "release" or for "development".

This could be easily achieved by properly setting WCC, WCC386, WPP and WPP386 with the /oh switch so it will be propagated to the tools.

[jmalak]

Sorry, it looks like you didn't understand what I tried to explain you. Do you think that OW programmers are so stupid (for years), that don't use compiler options which can add significant improvement of performance? Option -oh don't do this. We can not change anything only for posibility that we can and that it "could" improve something. We must be sure that it is realy what we expect and it is possitive. It is not argument that if OW with this option is build without crash then all is OK. If you want be serious and you can help with OW improvement you should think about following.

1. We should add -oh option to OW regression tests (none of existint tests use it).
2. We should do serious comparision of code with and without -oh option I mean on assebly code level to identify problems (if any) and to estimate performance gain. The size is only auxiliary information. OW build is generaly optimize for speed, but some parts are optimized by different criteria.
3. We should do serious time measurement for one bigger project for build time with -oh and without -oh option. It could be one of CG, C/C++ compiler, CRTL, etc.
4. After we get info above we can do conclusion if we use -oh option and for what.

Anyway, bellow is output from regular build server, that you can use it for comparision how long could take overall build process and each part of build process on your box.

Open Watcom Build Report (build on win32-x86)

Built through change   : b6e9f18ee7a30d5d931f19eb26ec0344f0b4f557 on 2014-09-09
Building through change: f6334b0684b67ebf22429b468366044a4cbd41b0

Compilers and Tools

CLEAN+BOOTSTRAP STARTED : 2014-09-09, 23:46 UTC CLEAN+BOOTSTRAP COMPLETED : 2014-09-09, 23:52 UTC

CLEAN+BUILD STARTED : 2014-09-09, 23:52 UTC CLEAN+BUILD COMPLETED : 2014-09-10, 02:55 UTC

Build Successful

REGRESSION TESTS STARTED : 2014-09-10, 02:55 UTC REGRESSION TESTS COMPLETED : 2014-09-10, 06:30 UTC

Fortran Compiler : Succeeded.
C Compiler       : Succeeded.
C++ Compiler     : Succeeded.
WASM             : Succeeded.

Documentation Build

CLEAN+BUILD STARTED : 2014-09-10, 06:30 UTC CLEAN+BUILD COMPLETED : 2014-09-10, 07:27 UTC

Build Successful

Installers build

INSTALLER BUILD STARTED : 2014-09-10, 07:28 UTC INSTALLER BUILD COMPLETED : 2014-09-10, 07:34 UTC

Post tasks

POST RUN COMPLETED : 2014-09-10, 07:36 UTC

git Messages

---

Already up-to-date.

git Messages end

[javiergutierrezchamorro]

Thank you for clarifying Jiri. I meant that most programmers link their programs with the OpenWatcom CRTL and Math lib, they do not compile their own. So if they are more efficient because -oh or whatever, they programs will be also more efficient. I will create detailed compilation time report, and after that run the regression tests with -oh, and after that, analyze the real impact on the generated code.

[TobiasKarnat]

What does the compiler option -oh change? Is there an upper limit on how many passes / time is spent on the code? If so and as the difference is only 10%, could there be options like -oh2 -oh3 be added?

[javiergutierrezchamorro]

According to the documentation: Option "oh" causes the compiler to attempt repeated optimizations (which can result in longer compiles but more optimal code).

No more details about it.