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.
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
