Hi! On Wed, Aug 19, 2020 at 07:18:02PM +0100, Richard Sandiford wrote: > > I have never seen the second case misfiring in practice, only the first > > one! > > Shucks, I guessed the wrong way round :-) > > I'd argue that the first check isn't a micro-optimisation though. > It's testing whether the duplication really is a duplication > (rather than a move).
Yes, by removing it the code is duplicated like in all other cases, but then the original is removed later (as dead code). With the check in place we have it appended to the predecessor block (by insn chain grafting instead of copying, done by cleanup_cfg). That is what I call a micro-optimisation. Of course it isn't correct in all cases (maybe those cases didn't happen before, maybe no one noticed; in any case, this patch makes it more robust, while still keeping it O(N)). > > The original patch is at > > https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551560.html > > btw. I'll prepare a testcase for that (it doesn't trigger with recent > > GCC versions though :-/ ) > > Hmm, OK. If the first check is the important one, then I think it'd > be better to make the max_size stuff conditional on !single_pred_p > rather than drop the test entirely. Okay, I'll look at that. Thanks, Segher
