[LLVMdev] Performance regression on ARM

Renato Golin renato.golin at linaro.org
Thu Oct 16 03:04:19 PDT 2014

On 16 October 2014 09:34, Hal Finkel <hfinkel at anl.gov> wrote:
> Interesting. Looks like the problem is in (219545, 219569].


> and given the magnitude of the change, I think that the trip-count changes are more likely.

Good point.

> Of course, all of these things are bug fixes :( -- So how do we follow-up on this?

Correctness before performance. Always.

I'll create a bug on this pointing to the delta for someone to
investigate. It doesn't have to be me, or the committer, the idea is
that this is not high priority. At least, not for now.

Once we have a way to track this more consistently, I think a good
approach is to be pragmatic. So, something along the lines of working
with the implementer, trying to understand the reason of the
regression. It could be a bad implementation or just a target-specific
reason for the regression. Depending on the importance of the
regression and of the patch, I'd consider turning it off for ARM (for
example, PR18996) and later investigating why.

I'd only consider reverting the patch in extreme circumstances, for
example, if we're close to a release AND the regression is big AND the
patch is a new feature, etc. I believe that's what you were concerned
about. :)


More information about the llvm-dev mailing list