On Thu, Jul 15, 2021 at 10:00 PM Andrew MacLeod <amacl...@redhat.com> wrote: > > On 7/15/21 9:06 AM, Richard Biener wrote: > > On Thu, Jul 15, 2021 at 1:06 PM Aldy Hernandez <al...@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.
Thanks a lot! Richard. > 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 >
