[LLVMdev] getelementptr being lowered to ptrtoint/.../inttoptr?
eli.friedman at gmail.com
Wed Feb 29 11:06:13 PST 2012
On Wed, Feb 29, 2012 at 11:00 AM, Dillon Sharlet <dsharlet at gmail.com> wrote:
> 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.
More information about the llvm-dev