Irini Stavrakantonaki via llvm-dev
2015-Oct-16 09:44 UTC
[llvm-dev] Break nested instructions?
Is there any pass that breaks an expression out of an instruction's operand into its own instruction, so that such nested instructions become explicit and are thus easier to work with in? e.g Following|call|instruction contains a|GEP|instruction as its first operand. Is there any pass which allows me to break up this: | %call = call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([4 x i8]* @.str4, i32 0, i32 0), i32 %tmp6) | into these: |%tmp = i8* getelementptr inbounds ([4 x i8]* @.str4, i32 0, i32 0) %call = call i32 (i8*, ...)* @printf(i8* %tmp, i32 %tmp6) | ? Thank you in advance, --istavrak -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151016/2dee4942/attachment.html>
On 16 Oct 2015, at 10:44, Irini Stavrakantonaki via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > Following call instruction contains a GEP instruction as its first operandNo it doesn’t. It contains a GEP constant expression. This is a bit confusing at first, especially when working with IRBuilder, which can sometimes give you constant expressions when you think that you’re asking for instructions. The constant expression, unlike an instruction, has no variable operands and no side effects, and so is guaranteed to be constant. There are passes that will do the opposite of what you’re requesting (turn side-effect-free instructions with constant operands into constant expressions), but nothing to work the other way around. This makes some things easier (you can easily see that the operand to the call is a constant, without having to look at the sequence of operations that generates it), but other things more difficult (you need to handle GEP instructions and GEP constant expressions). It would be quite nice to have a set of adaptor classes for the operations that can be either constant expressions or instructions, for use in the places where you don’t care which (just as CallSite wraps either an invoke or a call, in places that don’t need to handle them differently). There are a few thing that do make this easier: - Both Instruction and ConstantExpression are subclasses of Value - (I think) the OpCode for both will be the same, so you can switch on that and then only cast further if you care. David
Irini Stavrakantonaki via llvm-dev
2015-Oct-16 10:39 UTC
[llvm-dev] Break nested instructions?
On 16/10/15 12:59, David Chisnall wrote:> On 16 Oct 2015, at 10:44, Irini Stavrakantonaki via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> Following call instruction contains a GEP instruction as its first operand > No it doesn’t. It contains a GEP constant expression. This is a bit confusing at first, especially when working with IRBuilder, which can sometimes give you constant expressions when you think that you’re asking for instructions. The constant expression, unlike an instruction, has no variable operands and no side effects, and so is guaranteed to be constant. > > There are passes that will do the opposite of what you’re requesting (turn side-effect-free instructions with constant operands into constant expressions), but nothing to work the other way around. This makes some things easier (you can easily see that the operand to the call is a constant, without having to look at the sequence of operations that generates it), but other things more difficult (you need to handle GEP instructions and GEP constant expressions). > > It would be quite nice to have a set of adaptor classes for the operations that can be either constant expressions or instructions, for use in the places where you don’t care which (just as CallSite wraps either an invoke or a call, in places that don’t need to handle them differently). There are a few thing that do make this easier: > > - Both Instruction and ConstantExpression are subclasses of Value > > - (I think) the OpCode for both will be the same, so you can switch on that and then only cast further if you care. > > David >Thanks, David. I had misunderstood and thought that arguments were GEP instructions. Being GEP constant expressions, solves my issue! Thanks a lot again, --istavrak
Dear Irini, I wrote a pass for SAFECode that converts constant expressions into instructions. It is the BreakConstantGEP pass in SAFECode (http://llvm.org/viewvc/llvm-project/safecode/branches/release_32/lib/ArrayBoundChecks/BreakConstantGEPs.cpp?view=log). SAFECode has to change these to instructions because it needs to modify their results at run-time; you can update the code to a newer version of LLVM and use it if you wish. That said, converting constant expressions into instructions is almost always a bad idea. The compiler takes advantage of the fact that constant expressions are, well, constant to generate more efficient code. You should only convert constant expressions into instructions if you're going to make the constant non-constant (which is what SAFECode does). If you're trying to analyze LLVM IR, you should enhance your pass to understand constant expressions. Regards, John Criswell On 10/16/15 5:44 AM, Irini Stavrakantonaki via llvm-dev wrote:> > Is there any pass that breaks an expression out of an instruction's > operand into its own instruction, so that such nested instructions > become explicit and are thus easier to work with in? > > e.g Following|call|instruction contains a|GEP|instruction as its first > operand. Is there any pass which allows me to break up this: > > |%call = call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([4 x > i8]* @.str4, i32 0, i32 0), i32 %tmp6) | > > into these: > > |%tmp = i8* getelementptr inbounds ([4 x i8]* @.str4, i32 0, i32 0) > %call = call i32 (i8*, ...)* @printf(i8* %tmp, i32 %tmp6) | > > ? > > Thank you in advance, > > --istavrak > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- John Criswell Assistant Professor Department of Computer Science, University of Rochester http://www.cs.rochester.edu/u/criswell -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151016/20e84e92/attachment.html>