OK, you seem to be sensitive to questions about how compilers work and/or deliberately misinterpreting my questions, so I'm going to drop this.
-----Original Message----- From: [email protected] <[email protected]> Sent: Sunday, November 14, 2021 7:04 AM To: Phil Smith III <[email protected]> Cc: 'IBM Mainframe Assembler List' <[email protected]> Subject: Re: Curious compiler optimization On 2021-11-14 03:10, Phil Smith III wrote: >> 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. No it isn't. It contains a declaration and an initialization. >> 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. Rubbish. An LR instruction is one of the smallest and fastest. > This is code that will run billions of times, The body of the procedure will take far longer than the "LR". Compared to that code, the time taken by the LR will be negligible. And if it were to be run "billions" of times, you wouldn't be running it unoptimised. > often millions in a single run; > yes, we will feel it. No you won't. > 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? Because you asked it to. You specified no optimisation. > Note that I had the same ARCH() value on both versions. That's irrelevant. > So why wouldn't the > original code use the same fancy new instruction? Because you didn't ask for optimisation. > I would have assumed that optimization meant considering how > statements interact, not generating lousy code for each on purpose. Specifying optimisation does not generate lousy code "on purpose". Have you got your lines crossed? In any case, optimisation can involve optimisation within a statement; moving code from inside a loop to outside a loop; and improving the transition between statements. > 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...
