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

[Chandler Carruth]

Hey Hal,

The code is fine. The only question is whether these are good heuristics to
add.

I'm 98% confident about the -1 heuristic, but see below. I'm about 2%
confident about the power-of-2 heuristic. Powers of two happen for all
sorts of reasons, not just bitfields. I don't know that we can really
generalize from this with any realistic hope of accurate behavior
downstream.

On Mon, Oct 28, 2013 at 1:32 PM, Hal Finkel <hfinkel at anl.gov> wrote:

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

I'm extremely dubious of the literature here. That's being kind. I think
all of the literature here is pulling numbers out of thin air without any
realistic connection to optimizing real world application code. =/

I think it would be really useful to do justify any further heuristics with
benchmarks. FWIW, I'm happy with a story like: "This helps specific
benchmark X which is important to real application code, and doesn't cause
any regressions on the nightly test suite." I'm not expecting
across-the-board improvement (almost never happens), just that these are
motivated by actual code improving rather than just literature results, and
that they don't regress code that we know about.


>
> 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 can try to run them too, but honestly, I'd be interested in your specific
architectural impact given its greater sensitivity to changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131028/c9f2832a/attachment.html>