Hey Phil, For your OPT(3) compile, the MVHI instruction is the 4 byte flavor of series; MVHHI, MVHI and MVGHI. So as long as the high order bit of the immediate value in the 2nd operand is not turned on, zeros will be left extended in the 4 and 8 byte flavors of the instruction.
Regarding the 2nd operand on the store instruction, it does look unusual, and I would have expected an error. No clue. Mike -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Phil Smith III Sent: Thursday, November 11, 2021 6:59 PM To: [email protected] Subject: Curious compiler optimization Caution! This message was sent from outside your organization. IBM XLC on z/OS 2.4, under USS. With NOOPT: * int var = 0; LA r4,0 LR r0,r4 ST r0,var(,r13,160) That's an interesting way to clear a fullword, no? And I'm unclear what var(,r13,160) is supposed to be-the actual generated opcodes are 5000 D0A0 Which makes sense. Feels like there's an extra comma in there and an extra offset. Maybe this is the compiler's way of saying "This is tinkering with var, which is at offset 160"? I.e., it explicitly mentions both the variable name and the 160 for readability? With OPT(3): * int var = 0; MVHI var(r13,160),H'0' LA r0,0 Saner, but still a bit curious-halfword?? Maybe it's so clever it's reusing something that it knows is already half cleared!?! The LA r0,0 is in preparation for using it in a subsequent instruction, though that doesn't explain the redundant register tinkering in the NOOPT version. None of this matters-it all works fine-but it struck me as odd.
