Re: [COMMITTED] Denormalize VR_VARYING to VR_RANGE before passing it to set_range_info_raw.

On Mon, May 2, 2022 at 8:34 AM Richard Biener wrote: > > On Sun, May 1, 2022 at 2:15 PM Aldy Hernandez via Gcc-patches > wrote: > > > > We are ICEing in set_range_info_raw because value_range_kind cannot be > > VR_VARYING, since SSA_NAME_RANGE_TYPE can only hold VR_RANGE / > > VR_ANTI_RANGE. Mos

Re: [COMMITTED] Denormalize VR_VARYING to VR_RANGE before passing it to set_range_info_raw.

On Sun, May 1, 2022 at 2:15 PM Aldy Hernandez via Gcc-patches wrote: > > We are ICEing in set_range_info_raw because value_range_kind cannot be > VR_VARYING, since SSA_NAME_RANGE_TYPE can only hold VR_RANGE / > VR_ANTI_RANGE. Most of the time setting a VR_VARYING as a global > range makes no sens

[COMMITTED] Denormalize VR_VARYING to VR_RANGE before passing it to set_range_info_raw.

We are ICEing in set_range_info_raw because value_range_kind cannot be VR_VARYING, since SSA_NAME_RANGE_TYPE can only hold VR_RANGE / VR_ANTI_RANGE. Most of the time setting a VR_VARYING as a global range makes no sense. However, we can have a range spanning the entire domain (VR_RANGE of [MIN,MA