I don't know of any compiler that generates deliberately poor code. I know of lots of compilers that inadvertently generate poor code.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ 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... -----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??"
