This is the mail archive of the
`gcc-patches@gcc.gnu.org`
mailing list for the GCC project.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |

Other format: | [Raw text] |

*From*: Jan Hubicka <hubicka at ucw dot cz>*To*: Marc Glisse <marc dot glisse at inria dot fr>*Cc*: Jan Hubicka <hubicka at ucw dot cz>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Richard Biener <richard dot guenther at gmail dot com>*Date*: Thu, 24 Apr 2014 00:28:36 +0200*Subject*: Re: Optimize n?rotate(x,n):x*Authentication-results*: sourceware.org; auth=none*References*: <alpine dot DEB dot 2 dot 02 dot 1403011240500 dot 28536 at stedding dot saclay dot inria dot fr> <CAFiYyc2wWfrV4kMMewyBzz6m55jZW2TxmiD6x0sqtombs+OLYA at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1404131432090 dot 3577 at laptop-mg dot saclay dot inria dot fr> <CAFiYyc0grD-PGzgt3GQ5H76JnMFnsQy=pPicMu3sqjehtKU6Fw at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1404141703140 dot 3714 at laptop-mg dot saclay dot inria dot fr> <CAFiYyc3kcrmuw468kDp1fsRGDHTfQ376fovTKB5LYcnnQ3dzEg at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1404232021490 dot 4018 at laptop-mg dot saclay dot inria dot fr> <20140423211926 dot GA14089 at kam dot mff dot cuni dot cz> <alpine dot DEB dot 2 dot 10 dot 1404232333280 dot 4018 at laptop-mg dot saclay dot inria dot fr>

> > Thank you for the comments. If I understand correctly: > > - it is always ok to look at edge->probability (no need to check that the > probabilities are available as Richard feared) Actually with -fno-guess-branch-probabilities (default only at -O0) the probability is not computed. You can check profile_status >= PROFILE_GUESSED > - PROB_EVEN is an ok threshold for division (not sure I understood your last > sentence) > - for cheaper operations like addition, I should be less conservative and do > the transformation always, or use a threshold of PROB_UNLIKELY. PROB_EVEN is really coming from the way one value counter is implemented. If its probability is less than 50%, the value predicted may be wrong and may not be the most common value. It does not apply for your case. If you always eliminate branch, I would always disable the transformation only if the faster path you are going to slow down is more than PROB_LIKELY. For probabilities PROB_LIKELY...PROB_EVEN you are going to slow down the common path, but you will eliminate branch that is most likely data dependent and not well predictable. For really expensive operations (division by non-constant) you probably want to use PROB_EVEN. But perhaps for start you don't need to make a difference and lets see. > > Are there other operations than division (among those listed in > neutral_element_p or absorbing_element_p) that fall in the "expensive" > category? I guess there are some platforms where multiplication is > expensive, but few, and querying the target for the cost of operations > seems exagerated. So I would go with: > > [move definition of code_def] > if ((code_def == TRUNC_DIV_EXPR || code_def == CEIL_DIV_EXPR > || code_def == FLOOR_DIV_EXPR || code_def == ROUND_DIV_EXPR > || code_def == EXACT_DIV_EXPR) > && EDGE_PRED (middle_bb, 0)->probability < PROB_EVEN) > return 0; > > (and change the testsuite example with __builtin_expect to use division) > > or (my favorite): > > [move definition of code_def] > int threshold = PROB_UNLIKELY; > if (code_def == TRUNC_DIV_EXPR || code_def == CEIL_DIV_EXPR > || code_def == FLOOR_DIV_EXPR || code_def == ROUND_DIV_EXPR > || code_def == EXACT_DIV_EXPR) > threshold = PROB_EVEN; > if (EDGE_PRED (middle_bb, 0)->probability < threshold) > return 0; You may probably ask time estimate of estimate_num_insns for expensive operations. It is not terribly smarter than what you propose (modulo special casing the constant divisor), but this way we will have all the magic at one place that is good for maintanibility. With these changes it is OK. Honza > > > Is that ok, after re-testing? > > -- > Marc Glisse

**References**:**Re: Optimize n?rotate(x,n):x***From:*Marc Glisse

**Re: Optimize n?rotate(x,n):x***From:*Richard Biener

**Re: Optimize n?rotate(x,n):x***From:*Marc Glisse

**Re: Optimize n?rotate(x,n):x***From:*Richard Biener

**Re: Optimize n?rotate(x,n):x***From:*Marc Glisse

**Re: Optimize n?rotate(x,n):x***From:*Jan Hubicka

**Re: Optimize n?rotate(x,n):x***From:*Marc Glisse

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |