On Thu, Jun 24, 2021 at 09:31:13AM -0400, Andrew MacLeod via Gcc-patches wrote:
> We'll still compute values for statements that don't have a LHS.. there's
> nothing inherently wrong with that. The primary example is
>
> if (x_2 < y_3)
>
> we will compute [0,0] [1,1] or [0,1] for that statement, without a LHS. It
> primarily becomes a generic way to ask for the range of each of the operands
> of the statement, and process it regardless of the presence of a LHS. I
> don't know, maybe there is (or will be) an internal function that doesn't
> have a LHS but which can be folded away/rewritten if the operands are
> certain values.
There are many internal functions that aren't ECF_CONST or ECF_PURE. Some
of them, like IFN*STORE* I think never have an lhs, others have them, but
if the lhs is unused, various optimization passes can just remove those lhs
from the internal fn calls (if they'd be ECF_CONST or ECF_PURE, the calls
would be DCEd).
I think generally, if a call doesn't have lhs, there is no point in
computing a value range for that missing lhs. It won't be useful for the
call arguments to lhs direction (nothing would care about that value) and
it won't be useful on the direction from the lhs to the call arguments
either. Say if one has
p_23 = __builtin_memcpy (p_75, q_23, 16);
then one can imply from ~[0, 0] range on p_75 that p_23 has that range too
(and vice versa), but if one has
__builtin_memcpy (p_125, q_23, 16);
none of that makes sense.
So instead of punting when gimple_call_return_type returns NULL IMHO the
code should punt when gimple_call_lhs is NULL.
Jakub
