> 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
>
> Andrew
>
