[RFC] Return NULL from gimple_call_return_type if no return available.

Andrew MacLeod amacleod@redhat.com
Thu Jun 24 13:55:55 GMT 2021


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



More information about the Gcc-patches mailing list