[Bug ipa/81323] IPA-VRP doesn't handle return values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81323 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #9 from Jan Hubicka --- 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
[Bug ipa/81323] IPA-VRP doesn't handle return values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81323 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Andrew Pinski --- Fixed with r14-5628-g53ba8d669550d3 .
[Bug ipa/81323] IPA-VRP doesn't handle return values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81323 --- Comment #7 from Aldy Hernandez --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81323 --- Comment #6 from Andrew Macleod --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81323 --- Comment #5 from Jakub Jelinek --- *** Bug 109147 has been marked as a duplicate of this bug. ***
[Bug ipa/81323] IPA-VRP doesn't handle return values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81323 --- Comment #4 from Jakub Jelinek --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81323 Jakub Jelinek changed: What|Removed |Added CC||aldyh at gcc dot gnu.org, ||amacleod at redhat dot com --- Comment #3 from Jakub Jelinek --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81323
--- Comment #2 from Jakub Jelinek ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81323 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug ipa/81323] IPA-VRP doesn't handle return values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81323 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2017-07-17 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- We do not have "return functions" but all IPA propagations just work on the acyclic graph call arg -> callee. Eventually we have a dup for this somewhere.
