rjmccall added a comment. In D79378#2028705 <https://reviews.llvm.org/D79378#2028705>, @rsmith wrote:
> In D79378#2019336 <https://reviews.llvm.org/D79378#2019336>, @rjmccall wrote: > > > Is it reasonable to figure out ahead of time that we can skip the null > > check completely? It'd be kindof nice to also take advantage of this at > > -O0 whenever we don't have real work to do. > > > In simple cases, we could get a win at `-O0` (deleting an object or array > with a trivial (and therefore non-virtual) destructor + non-destroying > operator delete + no array cookie). Perhaps in those cases we could sidestep > the whole process and just generate a direct call to `operator delete`. > That's a different optimization from the one I'm suggesting here (which in > turn is trying to be the non-miscompiling subset of the original LLVM-side > optimization), though there's lots of overlap. If we don't care about the > `-Oz` cases where the destructor is non-trivial before optimization but can > be removed by the optimizer, then we could do that instead of this change. If > we decide we care about both situations (removing the branch at `-O0` for > trivial deletes and removing the branch at `-Oz` for deletes that optimize > into being trivial deletes), then I think we need both something like this > *and* that check. > > What do you think? I'm somewhat inclined to prefer special-casing deletes > that the frontend can see are trivial, rather than making the delete > unconditional under `-Oz`. That means we might see a code size regression in > some cases for `-Oz`, but I suspect that's mostly a theoretical risk. > > If we do special-case trivial deletes, should we still insert the branch for > them at `-O1` and above? In order for that to be profitable, I think the > branch would need to be both well-predicted and usually null, which seems > like it could happen but is unlikely to be the common case. I suspect the > best answer may be to do this regardless of optimization level. It doesn't have to be *usually* null, just null often enough that it pays for itself. I think that isn't that unlikely given that a lot of deletes are from abstracted locations like destructors. On balance, I think I'm okay with your current approach, as long as we document our assumption that skipping the check is not usually a performance win. I'm not too worried about the -O0 cost. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D79378/new/ https://reviews.llvm.org/D79378 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
