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

[Hanke Zhang via Gcc]

Richard Biener <richard.guent...@gmail.com> 于2023年10月4日周三 16:43写道：
>
> On Wed, Oct 4, 2023 at 10:37 AM Richard Biener
> <richard.guent...@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