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

Xinliang David Li via llvm-commits llvm-commits at lists.llvm.org
Sun Sep 3 22:26:35 PDT 2017


On Sun, Sep 3, 2017 at 5:08 PM, Sanjoy Das <sanjoy at playingwithpointers.com>
wrote:

> On Sun, Sep 3, 2017 at 4:49 PM, Xinliang David Li <davidxl at google.com>
> wrote:
> >> If we consider this to be a bug, then we can't fix it easily in SCEV
> >> expander alone.  IIUC with your change in both the cases above `%ptr`
> >> will be mapped into a `(add %p1 %p2)` SCEV expression, and so SCEV
> >> expander will have to conservatively assume that `(add %p1 %p2)` came
> >> from a `ptrtoint (add (inttoptr %p1) (inttoptr %p2))` (and have to
> >> expand accordingly), and this will regress alias analysis.
> >
> > The original alias information is already conservative, isn't it? This
> does
> > not seem to regress it.  By the way, a natural place to 'canonicalize'
> IR to
> > get rid of the intptr/ptrint might actually be in SCEV itself. If that is
> > the case,  teaching SCEV to understand them (possibly in a special mode
> as
> > Hal mentioned) might be unavoidable.
>
> If the original IR had the int<->ptr pattern then yes, the aliasing
> information is already conservative (so a round trip through SCEV and
> (conservative) SCEV expansion does not lose any information).
>
> However, if the original IR had a GEP (and not int<->ptr) and a
> SCEV->SCEVExpander round-trip gave us the ptrtoint version (which it
> would have to with your change, since by looking at the SCEV
> expression it can no longer determine whether the original IR used a
> GEP or a ptr<->int), we'd have regressed aliasing information.
>

SCEV itself can be canonicalized plus one bit to show it if is commutable.
If it is, generate the conservative/aliasing losing add form, otherwise
generate the GEP form.

However I find this situation extremely rare to be worth the effort: a
really deferencible pointer is used as an offset. If the pointer is not
dereferenced, the false aliasing does not really matter.

David


> -- Sanjoy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170903/5094bbe1/attachment.html>


More information about the llvm-commits mailing list