Peter thanks for all your help on this.
I agree with Seymour's statement below, and I consider the inability to
see dependencies that may exist as a compiler limitation.
For this reason, waiting for a long term formal solution, rather than
asking users to go through massive rework of their code, I think it
would be more appropriate for the optimizer to just let __asm statements
alone.
This would at least avoid producing incorrout.
Thank you,
mario
On 11/24/21 12:09 AM, Seymour J Metz wrote:
ObIsNotIsNotNotIs
In general the rule is if the compiler can see that
there is no dependency on any code,
the compiler is allowed to prune it.
Which is a different rule from "if the compiler can not see that there is a
dependency on any code , the compiler is allowed to prune it." The second applies to
the code, but not the first.
________________________________________
From: IBM Mainframe Assembler List <[email protected]> on behalf of
Peter Relson <[email protected]>
Sent: Tuesday, November 23, 2021 1:39 PM
To: [email protected]
Subject: Re: Curious compiler optimization
I discussed this with the C compiler team.
As was suggested, the reason for removal in Mario's case was that the
compiler had no knowledge that the __asm would do anything that would
effect the result. Side effects that could happen under the covers and
unknown to the compiler(that could be updates to variables, printf,
whatever) are simply not relevant to the discussion.
To paraphrase what I was told:
In general the rule is if the compiler can see that there is no dependency
on any code, the compiler is allowed to prune it. The __asm assembler text
is a black box. All that the compiler sees is the C variables in the
constraints. In this case, there are no identified side effects or writes
to anything relevant and hence cannot affect what the compiler believes is
the function's behavior (which as coded was to return "0").
I asked about how to get the __asm expanded anyway. There is already a
standards proposal to do just that. So that's something to look forward to
(possibly to be implemented by extending the "nodiscard" attribute). But
for now, you could
-- put that function in it's own translation unit (file) and compile that
with no optimization. Then any call should not optimize out the asm
statement.
-- have a #pragma option_override(asmFunct, "OPT(LEVEL,0)") in the same
source file with the function to avoid optimizing the code out
Peter Relson
z/OS Core Technology Design
