[LLVMdev] getelementptr being lowered to ptrtoint/.../inttoptr?

[Eli Friedman]

On Wed, Feb 29, 2012 at 11:00 AM, Dillon Sharlet <dsharlet at gmail.com> wrote:
> Hello,
>
> I am working on an application of LLVM where I would strongly prefer that
> getelementptr not be lowered into pointer arithmetic by any passes other
> than my own. I'm writing a ModulePass.
>
> I am observing a situation where I compile a C++ file with no optimization
> and I get code as I would expect that uses getelementptr. However, if I
> enable optimization with -O3, *some* of my getelementptr instructions are
> lowered to ptrtoint/add-mulinttoptr sequences, but not others.
>
> As far as I can tell, there is no advantage to what LLVM is doing here (such
> as re-using pointer arithmetic computations).
>
> The 'Often Misunderstood GEP page' makes it sound like optimization always
> replaces pointer arithmetic with GEP instructions at the end, even if it
> might be an 'uglygep' (is this an instruction? it isn't in the language
> reference) instead of a getelementptr. Is the problem that my pass is not at
> the end of the optimization passes? If this is the case,  how can I more
> effectively guarantee this? Right now I'm adding my pass immediately before
> MachineModuleInfo (after the verifier pass, if it is enabled).
>
> Another note, this only happens in a few programs I try to build, most of
> the time getelementptr is left unchanged through the compiler to my pass.
>
> Is there a way to prevent LLVM from doing this? Btw, I'm using LLVM 3.0.

It sounds like your pass is running after CodeGenPrepare?  I would
suggest not doing that.

-Eli