[COMMITTED] Add gimple_range_type for statements.

[Andrew MacLeod]

On 7/15/21 9:06 AM, Richard Biener wrote:
> On Thu, Jul 15, 2021 at 1:06 PM Aldy Hernandez <aldyh@redhat.com> wrote:
>>
>> Currently gimple_expr_type is ICEing because it calls gimple_call_return_type.
>>
>> I still think gimple_call_return_type should return void_type_node
>> instead of ICEing, but this will also fix my problem.
>>
>> Anyone have a problem with this?
> It's still somewhat inconsistent, no?  Because for a call without a LHS
> it's now either void_type_node or the type of the return value.
>
> It's probably known I dislike gimple_expr_type itself (it was introduced
> to make the transition to tuples easier).  I wonder why you can't simply
> fix range_of_call to do
>
>     tree lhs = gimple_call_lhs (call);
>     if (lhs)
>       type = TREE_TYPE (lhs);
>
> Richard.

You are correct. There are indeed inconsistencies, and they exist in 
multiple places.  In fact, none of them do exactly what we are looking 
for all the time, and there are times we do care about the stmt when 
there is no LHS.    In addition, we almost always then have to check 
whether the type we found is supported.

So instead, much as we did for types with range_compatible_p (), we'll 
provide a function for statements which does exactly what we need. This 
patch eliminates all the ranger calls to both gimple_expr_type ()  and  
gimple_call_return_type () .    This will also simplify the life of 
anyone who goes to eventually remove gimple_expr_type () as there will 
now be less uses.

The function will return a type if and only if we can find the type in 
an orderly fashion, and then determine if it is also supported by ranger.

Bootstrapped on x86_64-pc-linux-gnu with no regressions.  Pushed.

Andrew

-------------- next part --------------
A non-text attachment was scrubbed...
Name: type.patch
Type: text/x-patch
Size: 6446 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc-patches/attachments/20210715/b740cff9/attachment-0001.bin>