Here in the MVS development shop, we test and debug the code compiled at the optimization level with which it will be shipped. Doing otherwise would mask the source code bugs which have consequences only at a higher optimization
level, and would also mask the compiler code generation bugs which are only present at the higher optimization level. Your suggested techniques might make sense for simplistic environments where all of your problems can be recreated with an unoptimized compiles while running under an interactive debug tool. We certainly do not have that luxury in the operating system. Since we are routinely working with dumps, we have a great need to understand the translation from the source code language to the assembler or machine code. PL/X is compiled into assembler source code. We depend heavily on the PL/X compiler to generate symbol names which are relatable to the variable and field names in the source program, to aid us in understanding the translation. Fortunately for me, I don't deal much with C. My limited dealings with the pseudo-assembler listings generated by the IBM C compiler suggest that the IBM C compiler really sucks in that regard, at least compared to PL/X. With regard to the effects of optimization on understanding the translation, that can be a mixed bag. Some optimizations (especially those that move things a long distance) can increase the degree of difficulty. Others that reduce the amount of generated code by avoiding a lot of register reloading can make things easier, especially when you are tracing your way though some code (since there is less of it to trace). Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp. Poughkeepsie NY IBM Mainframe Assembler List <[email protected]> wrote on 01/31/2018 04:03:34 AM: > From: Robin Vowels <[email protected]> > To: [email protected] > Date: 01/31/2018 12:23 PM > Subject: Re: Fair comparison C vs HLASM > Sent by: IBM Mainframe Assembler List <[email protected]> > > From: "Keith Moe" <[email protected]> > Sent: Tuesday, January 30, 2018 11:08 AM > > > > One of the downsides to such great optimization is the added > difficulty in debugging. > > Such optimisations are rarely requested during debugging, > when all the facilities of the compiler - such as subscript bounds checking, > check for uninitialized variables, etc, are employed. > > > Programs will often have code that leaves footprints and saves > various values > > in work areas for diagnostic reasons. > > They might, but at run time, should an error occur in a PL/I program > the error-recovery unit can print the values of any requested variables. > > Also, for diagnostic purposes (either during debugging or during production), > values can be written to a file. > > > Many optimization algorithms will detect > > that these area are "never referenced" after being set and eliminate > > the code that sets or stores these values. > > See previous note. > > > Another optimization that makes debugging difficult is the > inlining of subroutines > > that are only called in one place to save the overhead of the linkage. > > But the generated mapping of the source to the generated machine > code/assembler > > does not match the original source statements to the generated machine code. > > I suppose it is possible, but the PL/I optimising compilers clearly > show where any moved code is placed. This is shown in the > assembler listing. > > > Sure, there are various tricks that can be done to prevent such > optimization, > > Such as not requesting optimising. > > > but that partially defeats the value of using a high level > language when you have to think about > > how to defeat it. > > > When you spend a lot of time debugging problems occurring in > customer production environments, > > life can be difficult. > > See earlier note about printing values from the error-recovery unit. > > > Optimization is great until it isn't! > > Keith Moe > Lead Developer > BMC Software, Inc. > > > --- > This email has been checked for viruses by Avast antivirus software. > https://www.avast.com/antivirus >
