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) > memset (ptr, 0, size); > > other_condition is false sufficiently often for this to be a noticeable > performance degradation. > > mysql 5.7 moved the above code around to explicitly call calloc or > malloc. Maybe to avoid this optimization? > > This patch restricts the optimization to require > a) malloc and memset in the same bb (of course, this is UB if malloc > returns NULL), or, > > b) memset in a single-pred block whose predecessor contains the malloc > call. AND the condition being a comparison of the malloc result against > NULL. > > For #b I only check for NE/EQ comparison, and don't bother determining > whether the test is the correct sense. If the user's written it the > wrong way round, we're in UB territory anyway. > > The existing tests for this optimization do not regress. The new test > shows the optimization being repressed, as expected. > > ok? > > nathan > > -- > Nathan Sidwell > > 83022.diff > > > 2017-11-17 Nathan Sidwell <nat...@acm.org> > > PR tree-optimization/83022 > * tree-ssa-strlen.c (handle_builtin_memset): Don't fold malloc & > memset if the condition is complicated. > > PR tree-optimization/83022 > * gcc.dg/tree-ssa/pr83022.c: New. 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?
Jeff
