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

[Manish Gupta]

Hey all,

Thanks all for such comprehensive feedback and apologies for delayed thanks
:) but every time i post on this mailing list i get so much more to know
about llvm.

Thanks again!!
Manish

On Sat, Aug 27, 2011 at 11:30 PM, John Criswell <criswell at illinois.edu>wrote:

>  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> 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         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
>>
>
>
>
> _______________________________________________
> LLVM Developers mailing listLLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110830/27eb3ab4/attachment.html>