llvm dev - Oct 2015 - 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 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

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>