From: IBM Mainframe Assembler List [[email protected]] on behalf of Phil Smith III
[[email protected]]
Sent: Saturday, November 13, 2021 11:10 AM
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?
No compiler generates "deliberately poor code".
In point of fact, it takes a great deal of programming design
and work to produce reasonably efficient code or better.
In some cases, it takes more code to deal with specific optimisations
that the extra code becomes bulky, and the designer must consider
this when designing the optimisation(s).
In general, optimisation takes extra compile time -- in some cases,
considerable extra time.
You have the choice of doing no optimisation or full optimisation.
No optimisation is often used when a program is being tested,
and you just want to know whether the program works or not.
In some compilers, an option is provided to omit code generation --
used when the user wants only a syntax check of the program.
I would have assumed that optimization meant considering how statements
interact, not generating lousy code for each on purpose.
You seem to believe that designers do this "on purpose". They don't.
Optimisation usually means "considering how statements interact".
It also can include eliminating common sub-expressions and of moving
invariant code outside a loop.
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...
-----Original Message-----
From: [email protected] <[email protected]>
Sent: Friday, November 12, 2021 9:07 PM
To: IBM Mainframe Assembler List <[email protected]>
Cc: Phil Smith III <[email protected]>
Subject: Re: Curious compiler optimization
On 2021-11-13 02:32, Phil Smith III wrote:
Thanks to all for the replies. I had clearly forgotten what MVHI did
(OK, I probably never knew-too many new instructions!).
As I said, it's not a problem, but I'm a bit bothered by your comment,
Peter:
So this is not a curious "optimization". It is a natural
non-optimization.
Seems like the unoptimized code is oddly crude.
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.
I suppose compiler authors
must fight the urge to do some basic optimization, but why would it
ever be this bad?
Is this bad? You would not notice the time to execute the redundant LR
instruction.
If you want better code, specify optimisation.
I do like the pseudo-assembler, putting as much info as possible in.
It just threw me since I was first wondering "Is there some new
assembler syntax I've missed??"
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
