On Sat, 28 Feb 2009, Joseph S. Myers wrote: > On Fri, 27 Feb 2009, Diego Novillo wrote: > > > We will be reading IL containing both overflow and non-overflow > > operations. We should define the combination rules for them. > > The rules are simple: > > * No transformation (of arithmetic operations, which is what we are > discussing here) may change defined behavior for given inputs to undefined > behavior for those same inputs. (The reverse transformation is permitted. > For example, a mixed set of addition/subtraction operations might usefully > be converted to all overflow-defined operations to allow the operands to > be rearranged and cancellation to take place. For example, if both > versions of a+b with the same operands are in use at some point, the > overflow-undefined version need not be computed, only the overflow-wraps > version.) > > * No transformation may change defined behavior for given inputs to > different, defined behavior for those inputs.
Indeed. A safe way of combining mixed trees is to just drop the *NV_EXPR variants to *_EXPR variants on the result. Consider (a -/nv 20) +/nv (b -/nv 20) where we see a re-association opportunity to combine both constants. The result is (a + b) - 40, _not_ (a +/nv b) -/nv 40. On trunk we have to disable this re-association because the result would still be undefined overflow (we don't have means to avoid this - other than doing the arithmetic unsigned and perform conversions of course). Richard.