Eric Botcazou <ebotca...@adacore.com> writes: >> The patch that adds poly_int has detailed documentation, but the main >> points are: >> >> * there's no total ordering between poly_ints, so the best we can do >> when comparing them is to ask whether two values *might* or *must* >> be related in a particular way. E.g. if mode A has size 2 + 2X >> and mode B has size 4, the condition: >> >> GET_MODE_SIZE (A) <= GET_MODE_SIZE (B) >> >> is true for X<=1 and false for X>=2. This translates to: >> >> may_le (GET_MODE_SIZE (A), GET_MODE_SIZE (B)) == true >> must_le (GET_MODE_SIZE (A), GET_MODE_SIZE (B)) == false >> >> Of course, the may/must distinction already exists in things like >> alias analysis. > > I presume that you considered using traditional operators instead of awkward > names, despite the lack of total ordering, and rejected it?
Yeah. E.g. for ==, the two options would be: a) must_eq (a, b) -> a == b must_ne (a, b) -> a != b which has the weird property that (a == b) != (!(a != b)) b) must_eq (a, b) -> a == b may_ne (a, b) -> a != b which has the weird property that a can be equal to b when a != b may/must matters in a similar way as it does for alias analysis: "may" usually selects conservatively-correct, just-in-case behaviour while "must" selects something that would be wrong if the condition didn't hold. > Because: > > - && (bitpos == 0 || MEM_P (target))) > + && (known_zero (bitpos) || MEM_P (target))) > > - && bitsize == TYPE_PRECISION (type)) > + && must_eq (bitsize, TYPE_PRECISION (type))) > > - if (need_to_clear && size > 0) > + if (need_to_clear && may_gt (size, 0)) > > is really ugly... Sorry about that. It's the best I could come up with without losing the may/must distinction. Thanks, Richard
