https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94566
--- Comment #13 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Andrew Pinski from comment #12)
> Aldy or Andrew, why in conv1 we don't get a range for
> SR.4_4 = sD.8798._M_valueD.7665;
>
> Even though the range we have is [-1,1] according to the
> __builtin_unreachable()?
> It seems like we should get that range. Once we do get that the code works.
> E.g. If we add:
> signed char *t = (signed char*)&s;
> signed char tt = *t;
> if (tt < -1 || tt > 1) __builtin_unreachable();
>
> In the front before the other ifs, we get the code we are expecting.
>
> conv2 has a similar issue too, though it has also a different issue of
> ordering for the comparisons.
its because the unreachable is after the branches, and we have multiple uses of
SR.4_4 before the unreachable.
<bb 2> [local count: 1073741824]:
SR.4_4 = s._M_value;
if (SR.4_4 == -1)
goto <bb 6>; [50.00%]
else
goto <bb 3>; [50.00%]
<bb 3> [local count: 536870913]:
if (SR.4_4 == 0)
goto <bb 6>; [50.00%]
else
goto <bb 4>; [50.00%]
<bb 4> [local count: 268435456]:
if (SR.4_4 == 1)
goto <bb 6>; [100.00%]
else
goto <bb 5>; [0.00%]
<bb 5> [count: 0]:
__builtin_unreachable ();
<bb 6> [local count: 1073741824]:
# _1 = PHI <-1(2), 0(3), 1(4)>
We know when we get to bb5 that SR.4_4 is [-1, 1] for sure.
But we dont know that before we reach that spot.
if there was a call to
foo(SR.4_4)
in bb 3 for instance, we wouldn't be able to propagate [-1,1] to the call to
foo because it happens before we know for sure. and foo may go and do
something if it has a value of 6 and exit the compilation, thus never
returning.
So we can only provide a range of [-1, 1] AFTER the unreachable, or if there is
only a single use of it.. the multiples uses are what tricks it.
This has come up before. we need some sort of backwards propagation that can
propagate discovered values earlier into the IL to a point where it is known to
be safe (ie, it wouldnt be able to propagate it past a call to foo() for
instance)
In cases like this, we could discover it is safe to propagate that range back
to the def point, and then we could set the global.
Until we add some smarts, either to the builtin unreachable elimination code,
or elsewhere, which is aware of how to handle such side effects, we can't set
the global because we dont know if it is safe at each use before the
unreachable call.
