Nobody has mentioned an interactive debugger, which might be why the
compiler creates code like this.
Joe Goovoo may not have a clue about the assembly code the compiler
generates, but he wants to modify variables at a breakpoint and the code
must use the changed value when he types "go". Optimized code is hard to
debug if you don't know assembler and have the listing.
From: IBM Mainframe Assembler List [[email protected]] on
behalf of Phil Smith III [[email protected]] Sent: Saturday, November 13,
2021 11:10 AM To: [email protected] Subject: Re: Curious
compiler optimization
Unoptimised code typically has redundant instructions.
For example, a store instruction to finish an assignment
operation might be followed by a load from the same place
in a following statement.
That I could believe--the unoptimized code is dealing with the statements as
discrete code snippets. But this was code generated for a single, simple
statement.
Is this bad? You would not notice the time to execute
the redundant LR instruction.
If that statement were true, there would be no need for optimization. This
is code that will run billions of times, often millions in a single run;
yes, we will feel it. Again, my point (well, one of them) was that this is
really pretty grim code: I'd downmark a student who produced it.
If you want better code, specify optimisation.
Corollary: the compiler generates...deliberately poor code without
optimization? Again, why?
Note that I had the same ARCH() value on both versions. So why wouldn't the
original code use the same fancy new instruction?
I would have assumed that optimization meant considering how statements
interact, not generating lousy code for each on purpose.
But I am not a compiler creator by any stretch of the imagination. Maybe I'm
missing some design principle here, which is why I asked in the first
place...
