On 03/04/2011 08:37 AM, Paolo Bonzini wrote: > On 03/03/2011 03:28 PM, Tom de Vries wrote: >> reg-tested on x86_64. Better? > > Yes, very much so
Great. Thanks for the review. > (talking about patch 6.5; the other one is an > optimization but not essential based on the new comments). > > Just one question: what happens if the COND_EXPR is indeed turned into a > MAX_EXPR? Is it a missed optimization? It is. It will take some effort to get cost calculation for MAX_EXPR ok. One additional problem (beside costs) that I observed also might need fixing: a new bound (containing a MAX_EXPR) is generated for an inner loop. The new bound is outer loop invariant. The MAX_EXPR however expands into control flow, and is not hoisted out of the outer loop, while the rest of the bound calculation is. > Is it because of overflow that > you aren't _always_ creating a MAX_EXPR directly? Indeed. The COND_EXPR created for my example is: ... (i + 1 <= n) ? (~i + n) : 0 ... where i and n are unsigned int. simplified: ... (i + 1 <= n) ? (n - (i + 1)) : 0 ... The condition i + 1 <= n precisely states the cases when n - (i + 1) does not underflow. Thanks, - Tom
