Add dummy optimization-level switches - #23724

messages should include rational "this $flag is for compatibility with ldc" and shouldn't use different terminology "this a dummy switch" is better then explaining what a dummy switch is passively

• Keep in mind, these switches are undocumented aside from the changelog entry.
• Those messages are not there to explain what the switches are meant to be used for. Instead they serve as a reminder to the unsuspecting user to clear up potential confusion.
• My current implementation emits those informational warning messages only for those switches that make no sense to use with DMD due to the lack of implementation. (i.e.: What’s the point of passing -Oz when the compiler doesn’t even try to generate a smaller binary?) They’d be errors if that didn’t defeat their purpose.

Im not criticizing adding dummy switches, Im criticizing the messages; imagine a purely hypothetical user who doesn't read the docs and just trys things, they try a "-O3" flag and it compiles as if it worked, this try "-Oz" and it says it replaced it with mystery config settings. Its all very spooky. Such a user would think theres a whole complex system about how dmd optimizes when there exactly, nothing.

"Ubiquitous Language", speak plainly, such a user trying optimization flags can be saved the effort of trying dozens of flags, writing benchmarks, by telling them these are dummy flags for ldc compatibility.

@crazymonkyyy
What’s your opinion on this diagnostic?

$ dmd -Oz test.d
Warning: This compiler does not support optimization for size.
       Will optimize for speed instead.
       Optimization-level switches are solely accepted for command-line compatibility with other compilers.

I don't see a use case in the rationale, it only says it "streamlines the user experience".

Back in the olden C daze, my compiler had lots of optimizer switches. You could control every aspect of how optimizations were done. This became a testing problem for me, as when there are n factorial combinations of switches controlling code generation, testing a release will consume time to the end of the universe. Nobody but me understood what those switches actually did, despite my attempts to explain them. Nor did they care in the slightest.

What people wanted is to "optimize" their code. Hence the simple -O. It's as streamlined as it can be.

As for size/space optimizations, the practical difference between them, especially on modern hardware, is not worth the bother. (And it already takes an hour to run the test suite.)

DMD will conditionally accept multiple differing optimization-level switches in one compiler invocation.
This is as long as they do not effectively contradict each other with reference to the activation of the optimizer

Having a set of switches that either do nothing or produce warning messages is not of value.

Also back in the olden C days, I wrote two shell programs. One for msc, the other for turboc. The shells would accept the commands for msc and turboc, and translate those switches to the closest Zortech switches, and then spawn the Zortech compiler. It worked tolerably well, and was not confusing to users (especially because the shells did not attempt to mix the Zortech/msc/turboc switches).

I'd be fine with writing such shells for dmd that will translate ldc/gcd switches to dmd switches.

I'd much rather see the optimization switches removed from DMD. Nobody is using DMD to optimize their binaries anymore, and it compares so poorly to LDC and GDC that it may be harmful to D's reputation to pretend that it's relevant. We could replace the optimizer code with a Thread.sleep() and nobody would even notice a difference.

@dkorpel

I don't see a use case in the rationale, it only says it "streamlines the user experience".

It makes DMD accept the same optimization switches that a user’s dmd binary would accept when it’s provided by LDMD2.

Basically, it allows for another case where DMD will happily accept the same command line that LDC, LDMD or GDC would accept — even when that involves, let’s say, -O2.

Which is handy for build scripts.

I'd much rather see the optimization switches removed from DMD. Nobody is using DMD to optimize their binaries anymore, and it compares so poorly to LDC and GDC that it may be harmful to D's reputation to pretend that it's relevant. We could replace the optimizer code with a Thread.sleep() and nobody would even notice a difference.

I’d rather keep the switches and just remove the functionality.
(To be honest, -release should probably emit an error and point the user to LDC or GDC in its message.)

@WalterBright

Having a set of switches that either do nothing or produce warning messages is not of value.

Please take a look at my implementation. They actually do something: They either turn on or off the optimizer.

My idea with the soft-warning — only emitted for -Oz/-Os/-Ofast — was to do so because DMD does not support those options to any extent.

The value is to have a command as simple as $DC -O2 -I"src" src/app.d just work — across compilers.

I'd be fine with writing such shells for dmd that will translate ldc/gcd switches to dmd switches.

I’m afraid, one can’t rely on these add-ons, because downstream packagers tend to omit them for their default installations. I recall a number of cases (reported on Discord) where someone got confused because they didn’t get companion tools like rdmd bundled with their downstream compiler package.