Function return value can't be infered when it's not inlined

Function return value can't be infered when it's not inlined

[Hanke Zhang]

Hi, I'm a little confused about the behavior of gcc when the function
is not inlined.

Here is an example code:

int __attribute__((noinline)) foo() {
    return 1;
}

int main() {
    if (foo()) {
        printf("foo() returned 1\n");
    } else {
        printf("foo() returned 0\n");
    }
    return 0;
}

After compiling this via `-O3 -flto`, the else block isn't been
optimized and still exists.

Even it's so obvious that the function will return '1', can't the
compiler see that? Does gcc only get this information by inlining the
function? Or is that what the gcc does?

If so, how to make a change to let gcc get this information then?

Thanks
Hanke Zhang

Re: Function return value can't be infered when it's not inlined

[Richard Biener]

On Tue, Oct 3, 2023 at 6:30 PM Hanke Zhang via Gcc <gcc@gcc.gnu.org> wrote:
>
> Hi, I'm a little confused about the behavior of gcc when the function
> is not inlined.
>
> Here is an example code:
>
> int __attribute__((noinline)) foo() {
>     return 1;
> }
>
> int main() {
>     if (foo()) {
>         printf("foo() returned 1\n");
>     } else {
>         printf("foo() returned 0\n");
>     }
>     return 0;
> }
>
> After compiling this via `-O3 -flto`, the else block isn't been
> optimized and still exists.
>
> Even it's so obvious that the function will return '1', can't the
> compiler see that? Does gcc only get this information by inlining the
> function? Or is that what the gcc does?
>
> If so, how to make a change to let gcc get this information then?

I think IPA-CP would be doing this but the issue is that historically
'noinline' also disabled other IPA transforms and we've kept that
for backward compatibility even when we introduced the separate 'noipa'
attribute.

Richard.

>
> Thanks
> Hanke Zhang

Re: Function return value can't be infered when it's not inlined

[Richard Biener]

On Wed, Oct 4, 2023 at 10:37 AM Richard Biener
<richard.guenther@gmail.com> wrote:
>
> On Tue, Oct 3, 2023 at 6:30 PM Hanke Zhang via Gcc <gcc@gcc.gnu.org> wrote:
> >
> > Hi, I'm a little confused about the behavior of gcc when the function
> > is not inlined.
> >
> > Here is an example code:
> >
> > int __attribute__((noinline)) foo() {
> >     return 1;
> > }
> >
> > int main() {
> >     if (foo()) {
> >         printf("foo() returned 1\n");
> >     } else {
> >         printf("foo() returned 0\n");
> >     }
> >     return 0;
> > }
> >
> > After compiling this via `-O3 -flto`, the else block isn't been
> > optimized and still exists.
> >
> > Even it's so obvious that the function will return '1', can't the
> > compiler see that? Does gcc only get this information by inlining the
> > function? Or is that what the gcc does?
> >
> > If so, how to make a change to let gcc get this information then?
>
> I think IPA-CP would be doing this but the issue is that historically
> 'noinline' also disabled other IPA transforms and we've kept that
> for backward compatibility even when we introduced the separate 'noipa'
> attribute.

Oh, and I forgot that IIRC neither IPA CP nor IPA SRA handle return
functions in a way exposing this to optimization passes (there's no
way to encode this in fnspec, we'd need some return value value-range
and record that and make VRP/ranger query it on calls).

Richard.

> Richard.
>
> >
> > Thanks
> > Hanke Zhang

Re: Function return value can't be infered when it's not inlined

[Hanke Zhang]

Richard Biener <richard.guenther@gmail.com> 于2023年10月4日周三 16:43写道：
>
> On Wed, Oct 4, 2023 at 10:37 AM Richard Biener
> <richard.guenther@gmail.com> wrote:
> >
> > On Tue, Oct 3, 2023 at 6:30 PM Hanke Zhang via Gcc <gcc@gcc.gnu.org> wrote:
> > >
> > > Hi, I'm a little confused about the behavior of gcc when the function
> > > is not inlined.
> > >
> > > Here is an example code:
> > >
> > > int __attribute__((noinline)) foo() {
> > >     return 1;
> > > }
> > >
> > > int main() {
> > >     if (foo()) {
> > >         printf("foo() returned 1\n");
> > >     } else {
> > >         printf("foo() returned 0\n");
> > >     }
> > >     return 0;
> > > }
> > >
> > > After compiling this via `-O3 -flto`, the else block isn't been
> > > optimized and still exists.
> > >
> > > Even it's so obvious that the function will return '1', can't the
> > > compiler see that? Does gcc only get this information by inlining the
> > > function? Or is that what the gcc does?
> > >
> > > If so, how to make a change to let gcc get this information then?
> >
> > I think IPA-CP would be doing this but the issue is that historically
> > 'noinline' also disabled other IPA transforms and we've kept that
> > for backward compatibility even when we introduced the separate 'noipa'
> > attribute.

Thanks. The initial example is a function that uses va_args as
parameters. It cannot be inlined because of va_args, and then its
return value cannot be predicted like above. For example, the
following function:

int foo (int num, ...) {
    va_list args;
    va_start(args, num);
    int a1 = va_arg(args, int);
    int a2 = va_arg(args, int);
    printf("a1 = %d, a2 = %d\n", a1, a2);
    va_end(args);
    return 1;
}

int main() {
    if (foo(2, rand(), rand())) {
        printf("foo() returned 1\n");
    } else {
        printf("foo() returned 0\n");
    }
    return 0;
}

Wouldn't such a function be optimized like 'noinline'?

>
> Oh, and I forgot that IIRC neither IPA CP nor IPA SRA handle return
> functions in a way exposing this to optimization passes (there's no
> way to encode this in fnspec, we'd need some return value value-range
> and record that and make VRP/ranger query it on calls).
>
> Richard.
>

Thanks. So, does that mean I have to let VRP/ranger be able to query
the return value so that the else block can be optimized out?

> > Richard.
> >
> > >
> > > Thanks
> > > Hanke Zhang

Re: Function return value can't be infered when it's not inlined

[Richard Biener]

> Am 04.10.2023 um 16:16 schrieb Hanke Zhang <hkzhang455@gmail.com>:
> 
> Richard Biener <richard.guenther@gmail.com> 于2023年10月4日周三 16:43写道：
>> 
>>> On Wed, Oct 4, 2023 at 10:37 AM Richard Biener
>>> <richard.guenther@gmail.com> wrote:
>>> 
>>> On Tue, Oct 3, 2023 at 6:30 PM Hanke Zhang via Gcc <gcc@gcc.gnu.org> wrote:
>>>> 
>>>> Hi, I'm a little confused about the behavior of gcc when the function
>>>> is not inlined.
>>>> 
>>>> Here is an example code:
>>>> 
>>>> int __attribute__((noinline)) foo() {
>>>>    return 1;
>>>> }
>>>> 
>>>> int main() {
>>>>    if (foo()) {
>>>>        printf("foo() returned 1\n");
>>>>    } else {
>>>>        printf("foo() returned 0\n");
>>>>    }
>>>>    return 0;
>>>> }
>>>> 
>>>> After compiling this via `-O3 -flto`, the else block isn't been
>>>> optimized and still exists.
>>>> 
>>>> Even it's so obvious that the function will return '1', can't the
>>>> compiler see that? Does gcc only get this information by inlining the
>>>> function? Or is that what the gcc does?
>>>> 
>>>> If so, how to make a change to let gcc get this information then?
>>> 
>>> I think IPA-CP would be doing this but the issue is that historically
>>> 'noinline' also disabled other IPA transforms and we've kept that
>>> for backward compatibility even when we introduced the separate 'noipa'
>>> attribute.
> 
> Thanks. The initial example is a function that uses va_args as
> parameters. It cannot be inlined because of va_args, and then its
> return value cannot be predicted like above. For example, the
> following function:
> 
> int foo (int num, ...) {
>    va_list args;
>    va_start(args, num);
>    int a1 = va_arg(args, int);
>    int a2 = va_arg(args, int);
>    printf("a1 = %d, a2 = %d\n", a1, a2);
>    va_end(args);
>    return 1;
> }
> 
> int main() {
>    if (foo(2, rand(), rand())) {
>        printf("foo() returned 1\n");
>    } else {
>        printf("foo() returned 0\n");
>    }
>    return 0;
> }
> 
> Wouldn't such a function be optimized like 'noinline'?
> 
>> 
>> Oh, and I forgot that IIRC neither IPA CP nor IPA SRA handle return
>> functions in a way exposing this to optimization passes (there's no
>> way to encode this in fnspec, we'd need some return value value-range
>> and record that and make VRP/ranger query it on calls).
>> 
>> Richard.
>> 
> 
> Thanks. So, does that mean I have to let VRP/ranger be able to query
> the return value so that the else block can be optimized out?

Yes (and compute a return value range).

Richard 

>>> Richard.
>>> 
>>>> 
>>>> Thanks
>>>> Hanke Zhang