Skip to content

Generalize def_exc ranges to not include 0#1723

Closed
sim642 wants to merge 2 commits intomasterfrom
def_exc-general-range
Closed

Generalize def_exc ranges to not include 0#1723
sim642 wants to merge 2 commits intomasterfrom
def_exc-general-range

Conversation

@sim642
Copy link
Copy Markdown
Member

@sim642 sim642 commented Apr 9, 2025

In relation to a thesis I'm supervising, the matter came up whether def_exc exclusion range (in bits) may be something like [4, 6], i.e. 15..63. Such things could arise from joining definite 15 and 63, for example. My intuition about the domain is that conceptually this should be fine.

Turns out that our implementation does not handle such things, but always requires the range to include 0. But this assumption doesn't seem to be documented anywhere, nor is it even asserted anywhere.
It was even difficult to find out that we have such implicit assumption. The reason we do is in how we construct exclusion ranges: always based on some ikind boundaries, i.e. in multiples of 8 and always including 0.

So in this PR I quickly tried to change that, but only for positive ranges for now by modifying IntDomain0.Size.min_range_sign_agnostic. Although it should be generalizable to negative ones as well.
A few things break immediately, but they seem to be also easily fixed. Although it's far from clear whether some abstract operations still make the implicit assumption.

Of course this begs the question whether we should have this. At some point I thought about removing the exclusion ranges entirely because all IntDomain operations now get ikinds, but I think the counterargument was that we can still find out slightly more precise things than the type with these ranges, particularly about booleans. So if we have the ranges, we should use them to their full potential like this.

@michael-schwarz
Copy link
Copy Markdown
Member

Personally, I am a bit skeptical about this, it seems like it is blurring the distinction between intervals and def_exc ranges even more?

Maybe we can align on what we want out of Def_Exc at a Gobcon?

@sim642
Copy link
Copy Markdown
Member Author

sim642 commented Apr 9, 2025

Maybe we can align on what we want out of Def_Exc at a Gobcon?

It's already on the agenda!

Personally, I am a bit skeptical about this, it seems like it is blurring the distinction between intervals and def_exc ranges even more?

It certainly brings them closer, but last time this was discussed there wasn't a clear plan to go either way with it.
Actually, one of the points was "It also serves as a built-in sign analysis" which isn't even true prior to this PR! So there seems to have been intuition that the ranges would give that, but they don't currently allow [1, ] (for positive) or [, -1] (for negative).

It would also be straightforward to make this configurable: general handling can also do everything we have right now.
The promoted cram tests even show cases where our witness invariants become simpler thanks to this.

@michael-schwarz
Copy link
Copy Markdown
Member

But they don't currently allow [1, ] (for positive) or [, -1] (for negative).

Is this not just Excluded {0} with a range containing zero?

@sim642
Copy link
Copy Markdown
Member Author

sim642 commented Apr 10, 2025

But they don't currently allow [1, ] (for positive) or [, -1] (for negative).

Is this not just Excluded {0} with a range containing zero?

For unsigned ikinds, things like Exc {0} [0,32] indeed would express being positive, but sign analysis of unsigned types isn't particularly meaningful. Also, most def_exc functions probably don't currently exploit such abstract values to their full extent, e.g. invariant_ikind gives 0 <= x && x != 0 as opposed to 1 <= x.

For signed ikinds, we don't really get a sign analysis because we have things like Exc {0} [-31,31] which cannot distinguish negative and positive. Even if trying to use exclusion set, the range would have to be different from what we currently allow, e.g. Exc {0} [0,31] (for positive) or Exc {0} [-31,0] (for negative).
So the tight ikind coupling is really preventing us from describing sign analysis in def_exc, even though the abstraction conceptually would be strong enough.

@sim642
Copy link
Copy Markdown
Member Author

sim642 commented Apr 15, 2025

The plan is not to go for this right now, but just document the implicit assumption in #1726.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants