[LLVMdev] How to break/iterate over nested instructions.

John Criswell criswell at illinois.edu
Sat Aug 27 23:30:00 PDT 2011


Dear Manish,

First, in answer to your original question: yes, there is a pass that 
will convert constant expression GEPs used within LLVM instructions into 
GEP instructions.  SAFECode has a pass called BreakConstantGEPs in 
safecode/trunk/lib/ArrayBoundChecks/BreakConstantGEPs.cpp 
(http://llvm.org/viewvc/llvm-project/safecode/trunk/lib/ArrayBoundChecks/BreakConstantGEPs.cpp?view=log).  
It works with LLVM 2.7; updating it to LLVM mainline should be trivial.

Second, to reiterate what others have said, you need to determine 
whether doing this conversion is a good idea.  Converting these constant 
expressions into instructions may very well hurt performance.  Blindly 
doing the conversion is really a quick hack (SAFECode for LLVM 2.7 
employed this hack more often than it should have; its performance was 
probably hurt as a result).  If all you're writing is an analysis pass, 
then you should make your analysis smart enough to analyze GEP constant 
expressions as Nick advised.

Third, for the curious, SAFECode had to convert constant expression GEPs 
into GEP instructions due to its pointer rewriting feature.  Basically, 
I needed to perform a run-time check on the constant expression GEP to 
make sure it was in bounds; if it was out-of-bounds, the check had to 
return a rewritten pointer value that would cause a fault on dereference 
(this is how SAFECode permits out-of-bound pointers that are never 
dereferenced; see the paper by Ruwase and Lam for more details).

SAFECode converted *all* constant expression GEPs into GEP 
instructions.  It really should have converted only those that went out 
of bounds (which were relatively few in real programs).  That's 
something I'll have to fix when I reintroduce BreakConstantGEPs into 
mainline SAFECode.
:)

-- John T.

On 8/27/2011 2:31 PM, Manish Gupta wrote:
> Hi Duncan,
>
> Why to break?
> I wish to analyse all the operands of getelemetptr instructions. For 
> which I iterate over the code and get the instruction of interest by
> getopcode == getelementptr. But the getelementptrs in this form as in 
> my last mail are getting away from my pass. So i wish to break it. I 
> have a work around if breaking is not possible, but I think it may be 
> a common requirement by other passes too.
>
> Thanks!
> Manish
>
> On Sat, Aug 27, 2011 at 12:41 AM, Duncan Sands <baldrick at free.fr 
> <mailto:baldrick at free.fr>> wrote:
>
>     Hi Manish,
>
>     > I wish to iterate over all instructions (where opCode ==
>     desired_opCode). I
>     > could iterate over all the instruction expect the nested
>     instructions like:
>     >
>     >   %add.ptr229 = getelementptr inbounds i8* getelementptr
>     inbounds ([4096 x i8]*
>     > @_Func1, i32 0, i32 0), i64 %idx.ext228
>
>     this is not a nested instruction.  The inner getelementptr is a
>     ConstantExpr
>     (a constant) not an instruction.
>
>     > I wish to break this nested instruction in two instructions.
>
>     Why?
>
>     Ciao, Duncan.
>
>      Please let me know
>     > if there is already existing method in llvm to do the job.
>     >
>     > Thanks,
>     > Manish
>     >
>     >
>     > _______________________________________________
>     > LLVM Developers mailing list
>     > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>     http://llvm.cs.uiuc.edu
>     > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>     _______________________________________________
>     LLVM Developers mailing list
>     LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu>
>     http://llvm.cs.uiuc.edu
>     http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110828/c8c156b9/attachment.html>


More information about the llvm-dev mailing list