> 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? 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... -- Eric Botcazou
