Re: [RFA][PATCH][PR tree-optimization/45685]

2013-12-13 Thread Richard Biener
On Wed, Dec 11, 2013 at 9:25 PM, Jeff Law wrote: > On 12/11/13 02:51, Richard Biener wrote: >> >> >> That looks wrong - you want to look at HONOR_NANS on the mode >> of one of the comparison operands, not of the actual value you want >> to negate (it's integer and thus never has NaNs). >> >> The r

Re: [RFA][PATCH][PR tree-optimization/45685]

2013-12-11 Thread Jeff Law
On 12/11/13 02:51, Richard Biener wrote: That looks wrong - you want to look at HONOR_NANS on the mode of one of the comparison operands, not of the actual value you want to negate (it's integer and thus never has NaNs). The rest of the patch looks ok to me. Here's the updated version. It addr

Re: [RFA][PATCH][PR tree-optimization/45685]

2013-12-11 Thread Jeff Law
On 12/11/13 02:51, Richard Biener wrote: + /* If inversion is needed, first try to invert the test since + that's cheapest. */ + if (invert) +{ + enum tree_code new_code + = invert_tree_comparison (cond_code, + HONOR_NANS (TYPE_MODE (TREE_TYPE

Re: [RFA][PATCH][PR tree-optimization/45685]

2013-12-11 Thread Jeff Law
On 12/11/13 08:11, Richard Biener wrote: Bah. That was supposed to be HONOR_SIGNED_ZEROS. Which as far as I can tell is a property of the value being tested. No, it's invert_tree_comparison (enum tree_code code, bool honor_nans) so indeed HONOR_NANS. And yes, on a conditional argument (it

Re: [RFA][PATCH][PR tree-optimization/45685]

2013-12-11 Thread Richard Biener
On Wed, Dec 11, 2013 at 3:51 PM, Jeff Law wrote: > On 12/11/13 02:51, Richard Biener wrote: >> >> >> First of all phiopt runs unconditionally for -On with n > 0 but the >> conversion >> is clearly not suitable for non-speed optimizations. Thus I'd guard it >> with at least !optimize_size && optim

Re: [RFA][PATCH][PR tree-optimization/45685]

2013-12-11 Thread Jeff Law
On 12/11/13 02:51, Richard Biener wrote: First of all phiopt runs unconditionally for -On with n > 0 but the conversion is clearly not suitable for non-speed optimizations. Thus I'd guard it with at least !optimize_size && optimize >= 2. As you are targeting a worse transformation done by if-c

Re: [RFA][PATCH][PR tree-optimization/45685]

2013-12-11 Thread Richard Biener
On Wed, Dec 11, 2013 at 7:54 AM, Jeff Law wrote: > > So for this source, compiled for x86_64 with -O3: > > typedef unsigned long int uint64_t; > typedef long int int64_t; > int summation_helper_1(int64_t* products, uint64_t count) > { > int s = 0; > uint64_t i; > for(i=0; i

[RFA][PATCH][PR tree-optimization/45685]

2013-12-10 Thread Jeff Law
So for this source, compiled for x86_64 with -O3: typedef unsigned long int uint64_t; typedef long int int64_t; int summation_helper_1(int64_t* products, uint64_t count) { int s = 0; uint64_t i; for(i=0; i0) ? 1 : -1; products[i] *= val; if