[PATCH] Tweaks for constant-equality-comparisons in BPI

Renato Golin renato.golin at linaro.org
Mon Oct 28 13:07:30 PDT 2013


Hi Hal,

Does this change have any relevant effect on other benchmarks?

I don't know that part of the code well, but I'm assuming this is only done
if you have no information on the variable being compared (ex. if it was
initialized with a power-of-two value, or -1).

cheers,
--renato


On 28 October 2013 00:42, Hal Finkel <hfinkel at anl.gov> wrote:

> Hello again,
>
> There are two other suggestions from (
> http://impact.crhc.illinois.edu/shared/papers/pact-98-branchpred.pdf)
> that I think would be useful to adopt in BranchProbabilityInfo (I've
> divided this into two patches, although the second applies on top of the
> first):
>
>  1. Treat equality comparisons to -1 as unlikely to succeed. As pointed
> out in the paper, -1 is often used as an 'invalid index' indicator, and,
> FWIW, many POSIX(-like) functions return -1 to indicate an error.
>
>  2. Treat single-bit tests as unlikely to succeed. The rationale is that
> when bit fields are used, the more-likely (default) case is for each bit to
> be unset. What I've done here is invert the result for an equality
> comparison with zero in the case where the comparison input is known to be
> a power of two or zero (and, thus, may only have one bit set).
>
>     For this second case, two regression tests needed updating:
>     CodeGen/AArch64/tst-br.ll
>     CodeGen/ARM/2013-10-11-select-stalls.ll (given the symmetry here, it
> is not clear to me why the number of stalls changes here at all; Andy?)
>
> I don't see any significant test-suite changes as a result of these (my
> x86 test environment timings are pretty noisy, however, so I've run
> multiple baselines and patched runs, and even so, would not really detect
> small changes).
>
> Please review.
>
> Thanks again,
> Hal
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131028/a70bdef5/attachment.html>


More information about the llvm-commits mailing list