[PATCH] D37419: Teach scalar evolution to handle inttoptr/ptrtoint

Sun Sep 3 00:50:46 PDT 2017

hfinkel added a comment.

In https://reviews.llvm.org/D37419#859829, @davidxl wrote:

> The class of inputs are usually generated by other optimizations such as SROA from C++ code --  the int/ptr conversions are usually not directly created by the user code.

SROA shouldn't be doing that. This is the last major problematic pass in the canonicalization part of the pipeline. It also hurts our ability to do AA on that code. Please just fix SROA. It should cast to i8* and use GEPs.

>   Logically speaking, handling of inttoptr/ptrtoint is no different from BitCast operation (ideally also implemented using BitCast op, but not doable due to IR spec), so there is no reason we should treat them as opaque while not doing so for BitCast.

We can't ever get rid of them completely, because the conversions are necessary for C/C++ lowering. That does not mean that we need to treat them as part of our canonical form. GEPs are much easier to deal with for AA and other kinds of simplification, and so we should canonicalize toward using pointer casts and GEPs. Especially in recent years, we've definitely been pushing in that direction. Having one canonical form in this regard keeps us from having to code many things twice (once for pointers and GEPs and once for ptrtoint/inttoptr + arithmetic).

> Unless we can fully get rid of these operations,  analysis passes will still have to deal with them. Missing handling those operations is simply a bug to be fixed independent of wether there is a pass to reduce/eliminate them.

I disagree. If we canonicalize away from them, then the only things left are things we really can't analyze anyway.

We might want some of the bug fixes from this patch regardless.

https://reviews.llvm.org/D37419