[PATCH] D102550: [ValueTracking] Mark GEP operand as nonnull if the result was loaded or stored

[Danila Kutenin via Phabricator via llvm-commits]

danlark marked an inline comment as done.
danlark added a comment.

In D102550#2761412 <https://reviews.llvm.org/D102550#2761412>, @nikic wrote:

> I'm somewhat concerned about the general direction here. This looks through a GEP, but what about bitcasts? What about a bitcast of a GEP? A GEP of a bitcast? A longer chain of GEPs and bitcasts? We can't reasonably walk the whole use graph and this is really pushing the bounds of what it appropriate for a ValueTracking helper.
>
> We have a more principled version of this optimization in LVI, which scans whole blocks for pointer dereferences and records their underlying objects, thus handling this in full generality. The only caveat is that LVI only uses this information to optimize the terminator instruction, because it does not store where exactly inside the block the first dereference occurs. If the motivation here is handling of non-terminator comparisons, then that might be a better avenue to explore?

I was looking at LVI and haven't come up with anything meaningful, probably because I am not familiar with that part.

I was following more a statistical approach at Google -- what the users do more with pointers, it turned out that dereferencing + check and pointer arithmetic+deref+check are the most common ones by far. That said, I found that deref+check is already optimized in ValueTracking and I decided to do the same with pointer arithmetic, however, yes, it starts to be a little bloaty. Also GCC does these kind of things with C/C++ code consistently and llvm is far behind in tracking the (non)nullness of pointers. 0.1% in big binaries looks like a big low hanging win.

Currently I don't want to go to LVI if I have a choice.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102550