Denormalize VR_VARYING to VR_RANGE before passing it to set_range_info_raw.
authorAldy Hernandez <aldyh@redhat.com>
Fri, 29 Apr 2022 20:46:25 +0000 (22:46 +0200)
committerAldy Hernandez <aldyh@redhat.com>
Sun, 1 May 2022 12:18:06 +0000 (14:18 +0200)
commit75bbc3da3e5f75f683fa33e309045c582efd20eb
tree705dc42dc3934fb9b7b6c01d0f2a7712f94da531
parent95874f95095f401405d3386e2e6695351b3f97b5
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,MAX] which is essentially a
VR_VARYING), if the nonzero bits are set.

This was working before because set_range_info_raw allows setting
VR_RANGE of [MIN, MAX].  However, when going through an irange, we
normalize this to a VR_VARYING, thus causing the ICE.  It's
interesting that other calls to set_range_info with an irange haven't
triggered this.

One solution would be to just ignore VR_VARYING and bail, since
set_range_info* is really an update of the current range semantic
wise.  After all, we keep the nonzero bits which provide additional
info.  But this would be a change in behavior, so not suitable until
after GCC 12 is released.  So in order to keep with current behavior
we can just denormalize the varying to VR_RANGE.

Tested on x86-64 Linux.

    PR tree-optimization/105432

gcc/ChangeLog:

* tree-ssanames.cc (set_range_info): Denormalize VR_VARYING to
VR_RANGE before passing a piecewise range to set_range_info_raw.
gcc/tree-ssanames.cc