On 6/2/21 1:52 PM, Richard Biener wrote:
On Wed, Jun 2, 2021 at 12:34 PM Aldy Hernandez via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
But the whole point of all this singing and dancing is not to make
warnings but to be able to implement assert (); or assume (); that
will result in no code but optimization based on the assumption.
That means that all the checks guarding __builtin_unreachable ()
should be removed at the GIMPLE level - just not too early
to preserve range info on the variables participating in the
guarding condition.
So yes, it sounds fragile but instead it's carefully architected. Heh.
In particular it is designed so that early optimization leaves those
unreachable () around (for later LTO consumption and inlining, etc.
to be able to re-create the ranges) whilst VRP1 / DOM will end up
eliminating them. I think we have testcases that verify said behavior,
namely optimize out range checks based on the assertions - maybe missed
Understood.
I will note that my proposed patch does not remove any unreachables, and
maintains current behavior. It just refines the ranges from the ranger
with current global ranges. So I think the patch should go in,
regardless of what is decided with __builtin_unreachables downthread.
the case where this only happens after inlining (important for your friendly
C++ abstraction hell), and the unreachable()s gone.
I have pointed this out before, and will repeat it in case you missed it:
"Richard, you have made it very clear that we disagree on core design
issues, but that's no reason to continually make snide comments on every
patch or PR. Can we keep the discussions focused on the technical bits?"
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/569072.html
