On 6/24/21 9:45 AM, Jakub Jelinek wrote:
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.
Well, we are going to punt anyway, because the call type, whether it is
NULL or VOIDmode is not supported by irange. It was more just a matter
of figuring out whether us checking for internal call or the
gimple_function_return_type call should do the check... Ultimately in
the end it doesnt matter.. just seemed like something someone else could
trip across if we didnt strengthen gimple_call_return_type to not ice.
Andrew
