hazzlim wrote:
> > The patch here is pretty big in size, but it seems to only affects the
> > remarks, on the other hand it doesn't seem to really fix anything and in
> > that case I feel like RC3 might be the wrong time to merge this. Is there a
> > huge upside to take this this late in the process?
> > Also ping @jroelofs as aarch64 domain expert and @AaronBallman as clang
> > maintainer.
>
> We had 8 release candidates for 18.x and I would _very much_ like to avoid
> that happening again, so I think that because we're about to hit rc3 (the
> last scheduled rc before we release according to the release schedule posted
> at https://llvm.org/) we should only be taking low-risk, high-impact changes
> such as fixes to regressions or obviously correct changes. I don't think this
> patch qualifies; is there significant risk to not putting this in? (e.g.,
> does this fix what you would consider to be a stop-ship level issue of some
> kind?)
Thank you for taking a look at this PR @AaronBallman. To reiterate points from
above, I do think that it is low risk (as it is very opt-in) and high impact in
the sense it helps to diagnose code that can incur a fairly significant
performance hit. However I appreciate we're almost at rc3 and so understand if
you don't think this qualifies for the 19 release at this stage.
https://github.com/llvm/llvm-project/pull/102168
___
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
