This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [ping patch] Predict for loop exits in short-circuit conditions
On Mon, Oct 8, 2012 at 4:50 AM, Dehao Chen <dehao@google.com> wrote:
> Attached is the updated patch. Yes, if we add a VRP pass before
> profile pass, this patch would be unnecessary. Should we add a VRP
> pass?
No, we don't want VRP in early optimizations.
Richard.
> Thanks,
> Dehao
>
> On Sat, Oct 6, 2012 at 9:38 AM, Jan Hubicka <hubicka@ucw.cz> wrote:
>>> ping^2
>>>
>>> Honza, do you think this patch can make into 4.8 stage 1?
>>
>> + if (check_value_one ^ integer_onep (val))
>>
>> Probably better as !=
>> (especially because GNU coding standard allows predicates to return more than
>> just boolean)
>>
>>
>> + {
>> + edge e1;
>> + edge_iterator ei;
>> + tree val = gimple_phi_arg_def (phi_stmt, i);
>> + edge e = gimple_phi_arg_edge (phi_stmt, i);
>> +
>> + if (!TREE_CONSTANT (val) || !(integer_zerop (val) || integer_onep (val)))
>> + continue;
>> + if (check_value_one ^ integer_onep (val))
>> + continue;
>> + if (VEC_length (edge, e->src->succs) != 1)
>> + {
>> + if (!predicted_by_p (exit_edge->src, PRED_LOOP_ITERATIONS_GUESSED)
>> + && !predicted_by_p (exit_edge->src, PRED_LOOP_ITERATIONS)
>> + && !predicted_by_p (exit_edge->src, PRED_LOOP_EXIT))
>> + predict_edge_def (e, PRED_LOOP_EXIT, NOT_TAKEN);
>> + continue;
>> + }
>> +
>> + FOR_EACH_EDGE (e1, ei, e->src->preds)
>> + if (!predicted_by_p (exit_edge->src, PRED_LOOP_ITERATIONS_GUESSED)
>> + && !predicted_by_p (exit_edge->src, PRED_LOOP_ITERATIONS)
>> + && !predicted_by_p (exit_edge->src, PRED_LOOP_EXIT))
>> + predict_edge_def (e1, PRED_LOOP_EXIT, NOT_TAKEN);
>>
>> Here you found an edge that you know is going to terminate the loop
>> and you want to predict all paths to this edge as unlikely.
>> Perhaps you want to use predict paths leading_to_edge for edge?
>>
>> You do not need to check PRED_LOOP_ITERATIONS and PRED_LOOP_ITERATIONS_GUESSED
>> because those never go to the non-exit edges.
>>
>> The nature of predict_paths_for_bb type heuristic is that they are not really
>> additive: if the path leads to two different aborts it does not make it more
>> sure that it will be unlikely. So perhaps you can add !predicted_by_p (e, pred)
>> prior predict_edge_def call in the function?
>>
>> I wonder if we did VRP just before branch predction to jump thread the shortcut
>> condtions into loopback edges, would be there still cases where this
>> optimization will match?
>>
>> Honza