"Richard Guenther" <[EMAIL PROTECTED]> writes: | On 12/31/06, Richard Kenner <[EMAIL PROTECTED]> wrote: | > > What would you suggest this function to do, based on your comments? | > | > I'm not familiar enough with VRP to answer at that level, but at a higher | > level, what I'd advocate is that the *generator* of information would track | > things both ways, assuming wrapping and non-wrapping semantics (of course, if | > -fwrapv or -fno-wrapv was specified, it would only do that one). Then the | > *user* of the information would decide which one to use by applying | > heuristics based both on the likelihood that the programmer would be relying | > on wrapping and the importance from an optimization standpoint of not doing so. | | For the VRP case I'd like to rework vrp_int_const_binop to behave like | int_const_binop (that wraps) and return if the operation overflowed. It's | much more readable to have the handling (or not handling) of overflow | at the callers site extract_range_from_binary_expression. Using | TREE_OVERFLOW as present is just wasting memory as an extra return | value will also do. | | So in the end it's probably time to re-work the core implementation of | int_const_binop to be more like | | tree int_const_binop (enum tree_code code, tree type, tree arg1, tree arg2, | int notrunc, bool *overflow); | | as it has all the magic to detect overflow already.
Can I interpret that as you volunteering to do it, or at least help? -- Gaby
