[Bug ipa/81323] IPA-VRP doesn't handle return values

[Bug ipa/81323] IPA-VRP doesn't handle return values

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Another testcase from a different PR:

__attribute__((noinline)) static int
foo (int a, int b)
{
  return a == b;
}

int
bar (int a, int b)
{
  return foo (a, b) != 0;
}

__attribute__((noinline)) static int
baz (int a)
{
  if (a > 10 || a < -10)
    return 0;
  return a;
}

int
qux (int a)
{
  return baz (a) == 42;
}

where if we determine that foo always returns [0, 1] and baz [-10, 10], then we
can
optimize that return ret != 0; into return ret; and ret == 42 into 0.

[Bug ipa/81323] IPA-VRP doesn't handle return values

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu.org,
                   |                            |amacleod at redhat dot com

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> We do not have "return functions" but all IPA propagations just work on the
> acyclic graph call arg -> callee.

Well, we don't need to propagate that immediately again, then I agree we'd need
to propagate the ranges through the whole program then.  All that would be
sufficient for start would be to remember the global ranges of the return
values and copy those to the callers.

[Bug ipa/81323] IPA-VRP doesn't handle return values

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Or the ranger could do it itself, similarly to how it handles .ASSUME, but
without actually querying anything but the global range of the return value if
any.  Though, doing that in the range means that we won't know ranges of
functions which with LTO are in a different partition, while doing it as IPA
optimization could allow even that to work.

[Bug ipa/81323] IPA-VRP doesn't handle return values

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
*** Bug 109147 has been marked as a duplicate of this bug. ***

[Bug ipa/81323] IPA-VRP doesn't handle return values

[amacleod at redhat dot com]

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

--- Comment #6 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Jakub Jelinek from comment #4)
> Or the ranger could do it itself, similarly to how it handles .ASSUME, but
> without actually querying anything but the global range of the return value
> if any.  Though, doing that in the range means that we won't know ranges of
> functions which with LTO are in a different partition, while doing it as IPA
> optimization could allow even that to work.

Aldy has been doing some IPA/LTO related cleanup with ranges... Hopefully we
can get this all connected next release.

[Bug ipa/81323] IPA-VRP doesn't handle return values

[aldyh at gcc dot gnu.org]

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

--- Comment #7 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #6)
> (In reply to Jakub Jelinek from comment #4)
> > Or the ranger could do it itself, similarly to how it handles .ASSUME, but
> > without actually querying anything but the global range of the return value
> > if any.  Though, doing that in the range means that we won't know ranges of
> > functions which with LTO are in a different partition, while doing it as IPA
> > optimization could allow even that to work.
> 
> Aldy has been doing some IPA/LTO related cleanup with ranges... Hopefully we
> can get this all connected next release.

I'm sitting on a patchset for GCC 14 that will revamp all the range handling in
ipa-*.* to be less ad-hoc, and use generic ranges (vrange even, so
type-agnostic).  The plan is to integrate this with the internal range storage
used by IPA (currently pairs of wide ints or value_range's) so that IPA at
least has the infrastructure to handle generic ranges.

Some discussion upstream is still needed, but the general idea should be
feasible for GCC 14.  It will be up to the IPA maintainers to handle floats/etc
internally though.

[Bug ipa/81323] IPA-VRP doesn't handle return values

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed with r14-5628-g53ba8d669550d3 .

[Bug ipa/81323] IPA-VRP doesn't handle return values

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org

--- Comment #9 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Note that  r14-5628-g53ba8d669550d3 does just the easy part of propagating
within single translation unit. We will need to add actual IPA bits into WPA
next stage1