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

[Hal Finkel]

----- Original Message -----
> 
> Hi Hal,
> 
> 
> Does this change have any relevant effect on other benchmarks?
> 

I really think that this depends on the platform. I have some internal codes for which I know that the -1 case helps. In looking through the (fairly sparse) literature on this topic, I found that PACT'98 paper. That paper suggests a number of heuristics based on an analysis of some set of SPEC benchmarks, many of which we already do. Of those that we don't currently implement, I think that there are three that are worth implementing now: The error-reporting functions (in the other BPI patch I posted), and the two cases in these patches. Both of these make intuitive sense to me, and seem fairly general.

Can you see if there is an effect of these (positive or negative) on ARM? I did not see much of an affect on my x86 build machine (which is really too noisy to run these kinds of comparative benchmarks). On the other hand, on my embedded PPC cores, getting better block placement has a larger effect.

> 
> 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).

Yes, it is essentially just looking at comparisons to constants.

Thanks again,
Hal

> 
> 
> 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
> 
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory