Problem understand optimization with inline asm

Problem understand optimization with inline asm

[Kalamatee]

[-- Attachment #1: Type: text/plain, Size: 1854 bytes --]

Good afternoon,

I have spent a while debugging an issue in an operating system I contribute
to, and it comes down to the behaviour of optimizing code.

We have code which is compiled for a native, or "hosted" (e.g. under linux)
environment, and have code which does the following -:

foo(struct mystruct1 *bar)
{
 int somevar = 0; // variable is initialized.
int anothervar = 0;
#if (some clause to check if it is not hosted)
asm volatile(
<some asm block which sets "somevar" if a feature is enabled, otherwise
leaves it as its initialized state>
: "=m" (somevar)
);
#endif
if (somevar)
{
//use the feature
 bar->param = 20;
anothervar = 1;
}
if (!anothervar)
{
 bar->param = 10;
}
)


Without optimization, the code works as intended for both the native and
hosted cases, but once optimization is enabled the following things appear
to happen.

(1) - gcc concludes the asm always overwrites somevar, and optimizes the
initialization away leaving it uninitialized.
(2) it doesn't now warn that the code is using an uninitialized variable
but silently compiles it as if all is well.
(3) at runtime if (somevar) has random contents, so runs the //use feature
case when it shouldnt.

Now, I can work around this by using "+" (even though I don't read the
variable), or initializing the value a second time in the asm block - but
should I have to? This sounds like the compiler is doing the wrong thing
based on the assertion/assumption "=" means I will 100% change some
variable, and worse after optimizing the code and creating a case where I
now have an uninitialized variable being used - does not warn me this is
happening?

Would it not be better to interpret "=" to mean "may" change the value,
which would prevent it incorrectly optimizing the initialization away, or
if it does warn that the value may be used uninitialized?

Yours,
Nick Andrews.

Re: Problem understand optimization with inline asm

[Andrew Haley]

On 3/28/23 12:15, Kalamatee via Gcc-help wrote:
> Now, I can work around this by using "+" (even though I don't read the
> variable), or initializing the value a second time in the asm block - but
> should I have to?

Yes.

> This sounds like the compiler is doing the wrong thing
> based on the assertion/assumption "=" means I will 100% change some
> variable,

That's what you've told GCC you will do. GCC doesn't look inside the asm
statement to see if you really do it.

> and worse after optimizing the code and creating a case where I
> now have an uninitialized variable being used - does not warn me this is
> happening?

You've told GCC that you initialized the variable, and GCC believes you.
If you lie to the compiler, it will get its revenge.

 > Would it not be better to interpret "=" to mean "may" change the value,
 > which would prevent it incorrectly optimizing the initialization away, or
 > if it does warn that the value may be used uninitialized?

If we did that we'd have to add another pattern which means "definitely
initialized". That would greatly complicate data flow analysis, for no
very good reason.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: Problem understand optimization with inline asm

[Andrew Haley]

On 3/28/23 12:41, Andrew Haley wrote:
> On 3/28/23 12:15, Kalamatee via Gcc-help wrote:

One other thing: you can pass the address of somevar into the asm and add a memory
clobber. That perhaps captures your intent.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: Problem understand optimization with inline asm

[Segher Boessenkool]

Hi!

On Tue, Mar 28, 2023 at 12:15:37PM +0100, Kalamatee via Gcc-help wrote:
> Now, I can work around this by using "+" (even though I don't read the
> variable), or initializing the value a second time in the asm block - but
> should I have to? This sounds like the compiler is doing the wrong thing
> based on the assertion/assumption "=" means I will 100% change some
> variable,

Yes, that is what an output contraint means.  From the manual:

  '='
       Means that this operand is written to by this instruction: the
       previous value is discarded and replaced by new data.

If you use "+" it will mean exactly what you want.  "+" means "both an
input and an output operand".

  '+'
       Means that this operand is both read and written by the
       instruction.

If you want the asm to have semantics like
  if (cond)
    x = y;
this can be equivalently written as
  if (cond)
    x = y;
  else
    x = x;
or maybe even
  x = (cond) ? y : x;
and written that way it is clear you really want an in/out constraint
here :-)

HtH,


Segher