[PATCH] D16890: Fix PR25339: ARM Constant Island
Renato Golin via llvm-commits
llvm-commits at lists.llvm.org
Mon Feb 8 06:51:45 PST 2016
rengolin added a comment.
In http://reviews.llvm.org/D16890#345099, @weimingz wrote:
> I'll post the test case shortly. Since it's based on proprietary code,
> it needs to complete some internal review process.
I completely understand. No worries.
> So far, I can only give a brief description of the problematic code.
> Please see https://llvm.org/bugs/show_bug.cgi?id=25339
Ah, excellent! That bug was on my radar, and I'm glad someone is looking at it. When you submit a review based on a bug, it's good to put the bug number like "Addresses bug #NNNN", so we can grab the rest of the context.
> The number 15 is half of the max threshold of 30.
Right. If the max is hard-coded, then maybe say max/2 in there?
It's also not clear to me why 15 is better than 30. If the algorithm fails to converge on both, than clearly either hard-coded numbers would be ok as long as the safe option is implemented. This patch seems to be doing both: forcing a convergence, even if a bad one (which would also work with 30 iterations, I think), and reducing the threshold to 15 (which doesn't make much sense per se).
> I did a measurement of building SPEC and the highest iteration number I
> see is 3.
This means that the application itself is problematic in that respect, so any number beyond 5 would be a good bet, with higher numbers better because they would only hit the worse cases.
What's the impact if you keep the original threshold?
cheers,
--renato
Repository:
rL LLVM
http://reviews.llvm.org/D16890
More information about the llvm-commits
mailing list