[PATCH] D113578: [SCEV] Apply loop guards when computing max BTC for arbitrary steps.

[Alexander Kornienko via Phabricator via llvm-commits]

alexfh added a comment.

(general discussion, not necessarily related to this patch)

In D113578#3192620 <https://reviews.llvm.org/D113578#3192620>, @reames wrote:

> In D113578#3192613 <https://reviews.llvm.org/D113578#3192613>, @alexfh wrote:
>
>> As for rapid vs delayed reporting, IMO, the main difference is whether the patch got dependencies (in LLVM code, in downstream LLVM dependencies, in code compiled by LLVM). Does it sound right to you?
>
> Can you rephrase this?  I'm not sure what you mean by "got dependencies", and am not sure what you're trying to ask here.

You mentioned quickly reported issues ("We will certainly fix upstream tests, common workloads, and quickly reported issues, but at some point, the responsibility shifts to the downstream maintainer. That's one of the reasons rapid reporting is so strongly encouraged."), and I wanted to gauge my understanding of this. I see multiple reasons why quickly reported issues may be handled differently:

1. as the time passes, the author of the patch may have switched context and it would be more effort to fix the issue;
2. the patch that caused the issue may be more difficult to revert cleanly or even changed significantly, when
  1. more patches landed touching the same lines of code
  2. other project code started depending on the new interfaces or behavior introduced by the patch
  3. something outside the project started depending on the new APIs, features, or behavior introduced by the patch.
3. the quicker the issue gets reported, the more the chances that it's a widespread issue with a higher impact.

Do these sound about right? Am I missing something else? What's your view on the relative importance of the factors above?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D113578/new/

https://reviews.llvm.org/D113578