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

[Alexander Kornienko via Phabricator via llvm-commits]

alexfh added a comment.

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

> In D113578#3188065 <https://reviews.llvm.org/D113578#3188065>, @alexfh wrote:
>
>> Unfortunately, the burden of mitigating the underlying issue in practice frequently lies with the author of the patch exposing the issue (unless someone else volunteers to do this).
>
> This isn't quite as clear cut as you make it out to be here.  Yes, we will frequently fix issues exposed in the process of introducing an unrelated bug.  However, the standard is not (and has never been) any reported issue which happens to be exposed.  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.
>
> To be clear, I'm not commenting on which this situation might be.  I'm just making the general point that this is a lot more complicated than your wording implies.

Thanks for the comment. Note that I used "frequently", not "always". I'm not trying to impose any rules, just stating my observation.

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?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113578