> When it needs zero, it merely copies it into anther > register that it has allocated?
Yes, but why not just store the register that they know a;ready contains zero? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List [[email protected]] on behalf of Robin Vowels [[email protected]] Sent: Thursday, November 11, 2021 9:17 PM To: [email protected] Subject: Re: Curious compiler optimization ----- Original Message ----- From: "Phil Smith III" <[email protected]> To: <[email protected]> Sent: Friday, November 12, 2021 10:58 AM Subject: Curious compiler optimization > 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? Maybe the compiler, seeing an initialization, establishes zero in register 0 and keeps it there. When it needs zero, it merely copies it into anther register that it has allocated? Anyway, it doesn't really need to use Register 4. > 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. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
