Re: [PR tree-optimization/83022] malloc/memset->calloc too aggressive

2017-11-17 Thread Jeff Law
On 11/17/2017 11:57 AM, Nathan Sidwell wrote: > On 11/17/2017 01:37 PM, Jeff Law wrote: > >> ISTM the better way to drive this is to query the branch probabilities. >> It'd probably be simpler too.  Is there some reason that's not a good >> solution? > > (a) I'd have to learn how to do that Yea,

Re: [PR tree-optimization/83022] malloc/memset->calloc too aggressive

2017-11-17 Thread Nathan Sidwell
On 11/17/2017 01:37 PM, Jeff Law wrote: ISTM the better way to drive this is to query the branch probabilities. It'd probably be simpler too. Is there some reason that's not a good solution? (a) I'd have to learn how to do that (b) in the case where the condition is just a null check, ma.cc

Re: [PR tree-optimization/83022] malloc/memset->calloc too aggressive

2017-11-17 Thread Jeff Law
On 11/17/2017 09:07 AM, Nathan Sidwell wrote: > We currently optimize a malloc/memset pair into a calloc call (when the > values match, of course).  This turns out to be a pessimization for > mysql 5.6, where the allocator looks like: > > void *ptr = malloc (size); > if (ptr && other_condition) >

[PR tree-optimization/83022] malloc/memset->calloc too aggressive

2017-11-17 Thread Nathan Sidwell
We currently optimize a malloc/memset pair into a calloc call (when the values match, of course). This turns out to be a pessimization for mysql 5.6, where the allocator looks like: void *ptr = malloc (size); if (ptr && other_condition) memset (ptr, 0, size); other_condition is false suffic