[erlang-questions] Dialyzer and numeric range values

[Tobias Lindahl]

Types need to collapse to a higher level of abstraction at some point or
the fixpoint iteration of the analysis might not terminate. Note that there
are an infinite number of ranges.

In order for the analysis to keep track of when to collapse the ranges
instead of expanding them, the structure of the analysis would have to take
into account some kind of history of range expansion (e.g., expand the
range X number of times, then collapse).

I spent quite some time on trying to use the ranges in Dialyzer in a better
way, but as I recall it, the non-termination was the reason for collapsing
early.

We used a more precise range analysis in the HiPE compiler for
optimization, and it is certainly possible to get good results for it, but
it is not as straightforward as it might seem.




2017-11-01 16:03 GMT+01:00 zxq9 <zxq9@REDACTED>:

> On 2017年11月01日 水曜日 07:27:35 Fred Hebert wrote:
> > On 11/01, zxq9 wrote:
> > >What is going on here? Is this a new thing with R20's Dialyzer, or have
> > >I just never noticed these multi-byte leaps in value range resolution?
> >
> > You never noticed it. Dialyzer kind of keeps the right to expand ranges
> > arbitrarily. You can see in the source code that anything set of types
> > above 12 gets merged into one:
> > https://github.com/erlang/otp/blob/fe1df7fc6bf050cb6c9bbd99eb9393
> c426b62f67/lib/hipe/cerl/erl_types.erl#L1997-L2011
> >
> > The same kind of stuff also happens with atoms or even types in general
> > (https://github.com/erlang/otp/blob/fe1df7fc6bf050cb6c9bbd99eb9393
> c426b62f67/lib/hipe/cerl/erl_types.erl#L4860-L4866)
> > which can be merged into the any() type.
> >
> > It's frankly a bit of a bummer but I figure it's something Dialyzer does
> > to be less memory-hungry, at the cost of accuracy.
>
> Hah! Wow. That's a pretty darn steep range curve on numerics!
>
> Incidentally, also one of the only apt uses of an `if` I've seen in a
> while.
>
> I've stayed away from Dialyzer internals for a reason (I get sort of
> obsessed about such things) but I wonder if it wouldn't be possible to
> establish numeric ranges as test ranges instead of enumerations?
>
> It seems like this is the case, actually, but obviously I am missing
> something if they can't set ?int_range(X, Y) directly and must instead only
> ever set either ?int_range(1, ?MAX_BYTE) or ?int_range(1, ?MAX_CHAR).
> https://github.com/erlang/otp/blob/fe1df7fc6bf050cb6c9bbd99eb9393
> c426b62f67/lib/hipe/cerl/erl_types.erl#L342
>
> The only place this approach seems to hold is called t_from_range_unsafe/2.
> https://github.com/erlang/otp/blob/fe1df7fc6bf050cb6c9bbd99eb9393
> c426b62f67/lib/hipe/cerl/erl_types.erl#L2018
> I assume "unsafe" for a reason, though the expected tests actually do
> exist.
> https://github.com/erlang/otp/blob/fe1df7fc6bf050cb6c9bbd99eb9393
> c426b62f67/lib/hipe/cerl/erl_types.erl#L2101
>
> Hm. So I'm just puzzled at the reasoning behind the need to enumerate
> ranges, and then the presence code that doesn't need ranges to be
> enumerated. Even more to the point, why not a list of arbitrary ranges? Too
> slow? Hard to imagine speed is the primary concern. Perhaps simply some
> work that never quite got polished off because, well, Dialyzer is already
> super useful in 90% of cases?
>
> Anyway, thanks for pointing that out. Quite interesting.
>
> -Craig
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20171108/963e19b8/attachment.htm>