[Bug c/106822] New: "Boolean-or" optimization opportunity not consistently used

[Bug c/106822] New: "Boolean-or" optimization opportunity not consistently used

[benjamin.meier70 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106822

            Bug ID: 106822
           Summary: "Boolean-or" optimization opportunity not consistently
                    used
           Product: gcc
           Version: 12.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: benjamin.meier70 at gmail dot com
  Target Milestone: ---

Hello

Assume the following code is given:

-----------------------------
#include <stdio.h>
#include <stdbool.h>

typedef struct {
    bool a;
    bool b;
} MyStruct;

bool f(const MyStruct *s)
{
    return s->a || s->b;
}

int main()
{
}
-----------------------------

If the code is compiled with -O3 I would assume it does not include any jumps,
because it should be valid to always read s->b (even if s->a is already true).
However, the function compiles into this:

-----------------------------
f:
        movzx   eax, BYTE PTR [rdi]
        test    al, al
        jne     .L1
        movzx   eax, BYTE PTR [rdi+1]
.L1:
        ret
-----------------------------
(see: https://godbolt.org/z/KdnzWb9Wh)


Interestingly, gcc will produce code without any jumps if MyStruct is slightly
modified:

-----------------------------
#include <stdio.h>
#include <stdbool.h>

typedef struct {
    int x;
    bool a;
    bool b;
} MyStruct;

bool f(const MyStruct *s)
{
    return s->a || s ->b;
}

int main()
{
}
-----------------------------

Generated code:

-----------------------------
f:
        cmp     WORD PTR [rdi+4], 0
        setne   al
        ret
-----------------------------
(see: https://godbolt.org/z/P78daxhhe)

It's not a bug, but I think it's a missed optimization opportunity.

Thanks

[Bug c/106822] "Boolean-or" optimization opportunity not consistently used

[benjamin.meier70 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106822

--- Comment #1 from Benjamin B. Meier <benjamin.meier70 at gmail dot com> ---
It might also be worth to note that the following code always compiles without
any jumps:
--------------------------------
bool f2(const MyStruct *s)
{
    return s->a | s ->b;
}
--------------------------------

Given that f and f2 should behave identical, I would assume that the optimized
code of them is similar "good" (e.g. does not contain any jumps)

[Bug tree-optimization/106822] "Boolean-or" optimization opportunity not consistently used

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106822

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The reason for the difference is because in the case where there is an int in
the structure, the alignment is 4 bytes so a 2 or 4 byte read for a and b will
not cause an fault while in the first case where there is no int, the alignment
is 1 and might cause a fault. Gcc is conservative here on doing the
optimization.

Also || is a short cutting or in c so I don't think this optimization can be
done for the original case in a well defined way.

[Bug tree-optimization/106822] "Boolean-or" optimization opportunity not consistently used

[benjamin.meier70 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106822

--- Comment #3 from Benjamin B. Meier <benjamin.meier70 at gmail dot com> ---
> The reason for the difference is because in the case where there is an int in the structure, the alignment is 4 bytes so a 2 or 4 byte read for a and b will not cause an fault while in the first case where there is no int, the alignment is 1 and might cause a fault. Gcc is conservative here on doing the optimization.

Okay, got it. The alignment actually makes a difference here. Thanks, for the
explanation.

> Also || is a short cutting or in c so I don't think this optimization can be done for the original case in a well defined way.

I see that as well, however reading the right hand side expression of the
||-operator has in this case no observable side-effect. Plus if we know that
s->a can be read, we know as well that s cannot be a NULL pointer. Given that,
I would assume the optimization should be valid (and applied).

Another supporting argument for ignoring the short cutting behavior is the
version of "MyStruct" with "int x;": In this case the compiler also always
reads both operands (and therefore ignores the short cut).

So if the compiler uses a nice optimization without jumps if it knows the
alignment is at least 2 bytes, it probably could also use an optimization for
the case that the alignment is only 1 byte. A possible optimization would then
look like the code of f2.

Finally, it's nothing really important, but I still do not yet completely see
why optimizing the jump away in f is an issue:)

[Bug tree-optimization/106822] "Boolean-or" optimization opportunity not consistently used

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106822

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
           Keywords|                            |missed-optimization
   Last reconfirmed|                            |2022-09-05
     Ever confirmed|0                           |1

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  The alignment consideration shouldn't apply in this case - the
MyStruct object is either there or not.  Note

typedef struct {
    bool a[];
} MyStruct;

bool f(const MyStruct *s)
{
    return s->a[0] || s->a[1];
}

would be a different story.

[Bug tree-optimization/106822] "Boolean-or" optimization opportunity not consistently used

[benjamin.meier70 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106822

--- Comment #5 from Benjamin B. Meier <benjamin.meier70 at gmail dot com> ---
Thx for the very quick reaction and also you additional example:)!