[LLVMdev] Performance regression on ARM (original) (raw)

Adam Nemet anemet at apple.com
Thu Oct 16 21:56:53 PDT 2014

On Oct 16, 2014, at 3:04 AM, Renato Golin <renato.golin at linaro.org> wrote:

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

Chandler’s complex arithmetic changes are also in the range: r219557 in clang. We saw it change the code in mandel-2 significantly.

Adam

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. :) cheers, --renato

LLVM Developers mailing list LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

More information about the llvm-dev mailing list