On Mon, Nov 4, 2024 at 4:52 PM Andrew MacLeod <amacl...@redhat.com> wrote: > > > > > >> Am 04.11.2024 um 16:32 schrieb Andrew MacLeod <amacl...@redhat.com>: > >> > >> > >>> On 11/4/24 10:27, Richard Biener wrote: > >>> > >>>>> Am 04.11.2024 um 16:01 schrieb Andrew MacLeod <amacl...@redhat.com>: > >>>> The invert() range operation is not supported on values of either > >>>> VARYING or UNDEFINED. Primarily this is because UNDEFINED has no type, > >>>> which makes it impossible to perform invert() twice on a value, and > >>>> produce that same value. There were also times when it wasn't precisely > >>>> clear what the client expects when UNDEFINED or VARYING is inverted.. so > >>>> it is handled at the caller point. > >>>> > >>>> When processing switches, whenever we find the ranges for a particular > >>>> label, we invert that range, and intersect that inversion with the > >>>> current "default:" ranges to determine the default case. In this > >>>> testcase, one label has all possible values, so the label was producing > >>>> VARYING. inverting that value was causing a trap. > >>>> > >>>> This patch simple checks for VARYING and sets the default ranges to > >>>> UNDEFINED in this case. > >>> Is that correct? The VARYING is not necessarily precise so „the rest“ > >>> should be VARYING as well? That said, I don’t think you can use invert > >>> and intersect to compute the default case range. > >> The varying *is* precise. It only comes up with varying if all the precise > >> values on each edge unioned together come out to varying. in this case, > >> boolean true and false. proiduces varying, leaving nothing for the default > >> cause. > > It never gets VARYING because too many incoming edges and thus > > conservatively merging subranges? I would doubt ranger can do precise > > ranges this way. 1 and 5 are conservatively [1, 5] but the inversion does > > not include 2 and thus is not conservative. > > > > Richard > > > No, that does not happen,at least it should not. If we have too many > edges to process (-param=vrp-switch-limit=) , we do not process the > switch at all. The limit is because processing massive numbers of > subranges can get expensive and ceases to be worthwhile after a while . > > we've generated the range for default this way since gcc12 at least. > Default starts with VARYING, and as we process each edge, we add the > ranges on the edge to the destination case, and remove those ranges from > the default case (hence invert and intersect). At the end, the range > for default contains all the ranges that do not reach a case label.
OK, so I looked and the important detail seems to be that we use int_range_max which actually has no "max" number of sub-ranges but dynamically grows, allowing for "exact" operation (assuming union and intersect never "give up" themselves). Richard. > Andrew >
