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
On 16 October 2015 at 11:39, Irini Stavrakantonaki via llvm-dev < llvm-dev at lists.llvm.org> wrote:> > > 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, >I think it's important to understand that this is not ALWAYS the case. The operands can be either a constant expression or an instruction. For example: char *a; int x; if(cond) a = "%d"; else a = "%x"; printf(a, x); In this case, the compiler may still be able to convert to constant expression for `a`, depending on if it's able to deduce `cond`. But if `cond` is not "constant", `a` will be a GEP instruction, not a constant expression. (Of course, the compiler will probably also warn that passing a variable to printf is a bad idea, but that's a different matter) -- Mats> > --istavrak > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151016/f71107b5/attachment.html>
Irini Stavrakantonaki via llvm-dev
2015-Oct-16 11:21 UTC
[llvm-dev] Break nested instructions?
On 16/10/15 14:09, mats petersson wrote:> I think it's important to understand that this is not ALWAYS the case. > The operands can be either a constant expression or an instruction. > > For example: > > char *a; > int x; > > if(cond) a = "%d"; > else a = "%x"; > printf(a, x); > > In this case, the compiler may still be able to convert to constant > expression for `a`, depending on if it's able to deduce `cond`. But if > `cond` is not "constant", `a` will be a GEP instruction, not a > constant expression. > (Of course, the compiler will probably also warn that passing a > variable to printf is a bad idea, but that's a different matter) > > -- > MatsDoes this mean that we can have a nested instruction into an instruction?! Wouldn't that lead having a LLVM IR language without terminals? --istavrak